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Abstract 



In this thesis the data analysis designed by author for the "Pi of the 
Sky" experiment is presented. The data analysis consists of data re- 
duction and specific algorithms for identification of short time scale 
astrophysical processes. The algorithms have been tested and their 
efficiency has been determined and described. The "Pi of the Sky" 
prototype is collecting data since June 2004 and algorithms could be 
intensively studied and improved during over 700 nights. A few events 
of confirmed astrophysical origin and above 100 events in 10s time 
scale of unknown nature have been discovered. During the data col- 
lection period 3 Gamma Ray Bursts ( out of 231 ) occurred in the field 
of view of the telescope, but no optical counterpart has been found. 
The upper limits for brightness of the optical counterpart have been 
determined. The continuous monitoring of the sky and own trigger 
for optical flashes allowed to determine limits on the number of GRBs 
without corresponding 7-ray detection. This allowed determining lim- 
its on the ratio of emission collimation in optical and 7 bands, which 
is -R < 4.4. The perspectives of the full "Pi of the Sky" system has 
been studied and number of positive detections has been estimated 
on the level of ^2.b events per year. 
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Introduction 



For thousands of years people believed that the sky is a constant being. The Uni- 
verse was believed to be eternal and unchanged. This idea has been questioned by 
Galileo Galilei who used supernova discovered by Johannes Kepler in 1604 as an 
argument. Since that time big progress in astronomy was achieved. The Universe 
is not believed to be eternal and unchanged anymore. Several observations prove 
that the Universe began in the Big Bang, about 14 billion year ago and this is the 
well established theory now. The evolution of the Universe is studied as well as 
evolution of its components. The evolution of stars is quite well understood and 
it is now well known fact that these objects evolve. The timescale of this evolu- 
tion in comparison the human life is huge. However, there are many processes 
in the Universe which occur in much smaller timescales. The first example can 
be already mentioned process, supernova explosion. These events occur at the 
end of star life and timescale of the explosion itself starts on the level of seconds. 
Recent observations suggest that the most violent and spectacular processes in 
the Universe occur in timescales of seconds. Among these processes the most 
energetic are Gamma Ray Bursts (hereafter GRB), which were main motivation 
of this thesis. The GRBs are processes occurring in timescales ranging from mil- 
liseconds to hundreds of seconds. In order to study such rapid processes in optical 
domain a new approach was required. Such a need triggered development of the 
"Pi of the Sky" project. Data analysis presented in this thesis was performed 
on the data collected by the "Pi of the Sky" detector, which was optimized for 
investigating short timescale astrophysical processes with main focus on GRBs. 
The thesis is divided in five chapters. In the first chapter short timescale astro- 
physical processes are reviewed with main focus on GRB. In the second chapter 
the "Pi of the Sky" experiment is presented, with several technical solutions 
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described in details. The third chapter contains description of data analysis, 
including description of flash recognition algorithms created by author. In the 
fourth chapter results and perspectives for future are presented. 



Chapter 1 

Short timescale astrophysical 
phenomena 

For centuries astronomical observations were performed in fong timescales. It 
was mainly due to instrumental limitations. Evolution of stars and the Universe 
is a very slow process, so for long time it was enough for understanding many 
astrophysical processes in the Universe. The main limitation was due to detec- 
tors, since the middle of XIX century photographic films were used. They didn't 
allow for short exposures due to very poor quantum efficiency. The next genera- 
tion of detectors, photomultipliers allowed much better time resolution, however 
they were limited to observations of single object. Big progress in electronic tech- 
nologies allowed to introduce new type of detectors Charged Coupled Devices ( 
CCD ). This type of detector together with computers gives a powerful tool to 
the researchers. Using the CCD detectors it is possible to perform astrophysi- 
cal observations with time resolution of seconds. Except the optical domain big 
progress was also achieved in the area of X-ray, gamma and particle detectors, 
which allowed to begin studies of the Universe in other bands. Progress in de- 
tector techniques allowed to monitor simultaneously many objects in short time 
scales. We now know that there is a number of such fast astrophysical events 
occurring on very short timescales down to milliseconds. List of interesting as- 
trophysical processes acting in short timescales is long. The most rapid, but still 
possible to observe are listed below : 

• Gamma Ray Bursts (GRB) 



• Supernovae stars 

• Active Galactic Nuclei (AGN) in particular blasars 

• Nova stars 

• Flare and other variable stars 

It seems that the most violent astrophysical processes occur on short timescales. 
In most cases optical observations of these fast processes are performed some time 
after the main explosion, when new object is observed in the sky or signal from 
other bands is detected and distributed to the community. Due to sudden char- 
acter of these events it is very difficult to catch such event when it is going on. 
This is a strong motivation for wide field observations. Such observations give a 
big chance to discover many events with fiash-like signature, when suddenly new 
object appears in the sky. Such signal may be used as trigger signal for other 
experiments to observe. The "Pi of the Sky" experiment was designed to be a 
good tool for performing this kind of observations. 

1.0.1 Gamma Ray Bursts 

The GRBs are the most violent and energetic events known in the Universe. They 
were first observed in late 60s by American satellites Vela 0|. For many years 
they were the most mysterious astrophysical processes. The main problems of 
early GRB researchers were the following : 

• Origin - are the GRBs galactic or extra-galactic ? The extra-galactic origin 
of GRBs would require huge energetics of these processes which was very 
hard to accept by the researchers. 

• If extragalactic, how such amounts of energy can be produced ? 

• What is the central engine and progenitor responsible for such kind of ex- 
plosion ? 



A large progress was achieved in 90s due to BATSE instrument on CGRO 
satellite which detected 2700 GRBs. This allowed to determine the spatial dis- 
tribution of the GRBs (Fig. Il.ip giving a strong argument for cosmological origin 
of the GRBs. Another success of the BATSE mission was discovery of 2 classes 
of short and long GRBs (Fig. II. 2p . It seems that these two kinds of GRBs are 
caused by different processes. 
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Figure 1.1: Spatial distribution of 2704 GRBs detected by BATSE detector on board the CGRO 
satellite {^) 
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Figure 1.2: Duration of GRBs detected by BATSE detector on board the CGRO satellite ([1| 



Figures 11.31 and 11.41 show examples of 7-ray light curves of long and short 
GRBs observed by the SWIFT satellite Final prove of extragalactic origin 
of the GRBs was provided by the Beppo-SAX satellite which on 1997-02-28 ob- 
served the first X-ray afterglow of the GRB970228. The Beppo-SAX observation 
of GRB971214 allowed determination of its redshift z=3.1418 , which confirmed 
extragalactic origin of GRBs. The cosmological origin of GRBs was well estab- 
lished after redshifts were measured for many more bursts. This fact implied 
huge energies produced in the explosion of the order of 10^^ ergs when isotropic 
emission is assumed. 

The data collected by orbital missions (Tab. II. ip and ground base telescopes 
allowed to formulate the fireball model (Fig. II. 5p which can describe most of the 
properties of GRBs [lO||. The energy is produced by the central engine which in 
case of long bursts is believed to be collapse of the massive star in the so called 
Vollapsa." scenario and i. is a version of snpernova explosion (H.Q.Q.Q). 
In case of the short bursts the central engine is believed to be a merging of two 
compact objects in .he bi„a,v system (Qfl.H.H). Such compact objects 
can be two neutron stars or neutron star and a black hole. 




Figure 1.3: Examples of long GRBs observed by SWIFT satellite in years 2006 and 2007 (|2|) 




Figure 1.4: Examples of short GRBs observed by SWIFT satellite in years 2006 and 2007 ([2|) 
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FOV=47r, B^=20keV-600keV 
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tion, detection of 2700 GRBs 
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X and Optical afterglows 
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tected and localized 


Swift 
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Table 1.1: Past and future satellite missions most important for understanding the Gamma 
Ray Bursts 
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Figure 1.5: Fireball model of the GRB ( image from 0| ) 



The central engine explosion causes ejection of matter in the collimated jet. 
The matter is ejected in packets called "shells" with different Lorentz factors T ^ 
100 causing internal shocks when slower shells are crashed by faster shells ejected 
later. This internal shocks mechanism is believed to produce the gamma rays 
observed as the GRB event. The ejected matter finally reaches the interstellar 
medium ( ISM ) and the collision with ISM causes the external shock. This 
processes is believed to be responsible for the optical counterparts of the GRBs 
so called "afterglows" which were observed for a number of bursts. Currently for 
about 50% of GRBs optical counterparts are observed ( see Sec. 14.5.41 ). The 
jet opening angle was determined for number of bursts from the jet break time 
to be few degrees, which reduces the total GRB energy by factor of ~100. 
Since the discovery of the GRBs a large progress in their understanding has been 
achieved, however, the main question how the central engine works still remains 
unanswered. There are also many other uncertainties and doubts concerning 
mechanisms of jet production etc. More multiwavelength data is required to 
understand better these processes. Especially optical data is very important for 
understanding the puzzle of the GRB. Due to technical limitations for many 
years optical counterparts of GRBs were observed many hours or even days after 
the gamma emission. For long time, in fact until SWIFT satellite was launched 
in 2004, there was only one event 990123 [3| for which the optical signal was 
observed when the GRB was still going on (Fig. II. 6p . For most of the bursts 
position, if known, was determined long time after the GRB, causing optical 
observations to be delayed. 

Improvement of detection techniques allowed to measure the GRB position 
just after the gamma detection. In order to rapidly distribute alerts with burst 
position and time, the Gamma ray bursts Coordinates Network ( GCN ) was 
developed (Fig. II. 7p . The system works in such a way that in case GRB is 
detected by any of the satellites and its position is determined, it is distributed 
among the registered observatories. They point their telescopes to the burst 
position and look for signal in other bands. Big immovable detectors of other 
messengers like neutrinos or gravitational waves try to find signal correlated in 
time and space with GRB, so far such correlation was not found. 




Figure 1.6: Observation of prompt optical signal from GRB990123 by ROTSE (left image) and 
GRB041219 by RAPTOR (right image). In the case of GRB041219 the optical signal variability 
is correlated with 7 emission while in the case of GRB990123 it is not 



New era of optical and X-ray GRB research was opened by the launch of the 
SWIFT satellite on November 20, 2004 ( [aofl , [211 ) 



1.0.2 Optical counterparts in SWIFT era 



The SWIFT satellite is dedicated to GRB research [5||. It has three scientific 
instruments on board (Fig. II. Sp . which are : 



• Burst Alert Telescope ( BAT ) - gamma detector works in energy band 
15-150 keV. This instrument detects GRBs and uses coded mask technique 
to determine their positions with the accuracy of ~2-3 arcmin. It has large 
Field Of View (FOV) ^2 steradians. 

• X-Ray Telescope ( XRT ) - X-ray detector works in energy band 0.2-10 keV. 
After the BAT detects the GRB, XRT is able to determine the position of 
the X-ray counterpart with the precision of 3 arc sec. 

• UV/Optical Telescope ( UVOT )- this is the optical telescope. After the 
position is determined by the BAT detector, the satellite slews to the burst 




Figure 1.7: The Gamma ray bursts Coordinates Network ( image from 0| ) 



position and X-ray and optical observations are performed. The limiting 
magnitude of the UVOT is 20"^ which allows to detect even very faint 
objects. The reaction time of UVOT is limited by the slewing time and is 
on average 40-100 sec ( see Fig. 14.161 ). 



The 5M^//f satellite 



UVOT 




UV/QPTICAL 
TELESCOPE 

* Imaging: 1700-6500 A 

* Precision: 0.5 arcsec 

* Sensitivity: \/ = 20 



BURST ALERT 
TELESCOPE 

* Imaging: 15-150 keV 

* Precision: 2-3 arcmin 

* Field of view: 1/6 of sky 



X-RAY TELESCOPE 

* Imaging in 0.2-10 keV 

* Precision: 3 arcsec 

* Sensitivity: 2x10-^'^cgs 



Figure 1.8: Main scientific instruments on board the SWIFT satellite ( jH| 



The SWIFT satellite allowed to access the "dark area" of GRB early optical 
and X-ray data. It became possible to observe X-ray and optical counterparts 
seconds after the burst. Using XRT it became possible to discover previously not 
observed early X-ray flares. The fast position determination allowed UVOT, but 
also ground base telescopes to observe optical signal only seconds after the gamma 
ray detection. It became clear that not all GRBs have bright optical counterpart. 



Since the launch till this moment ( Oct 2007 ) SWIFT detected over 240 GRBs 
and for less then half of them optical counterpart was observed ( Tab. 14.131 
on page 11521 ) . Early bright optical detections are listed in the Table 14.141 on 
page 11531 it is clear that only small fraction of GRBs have very bright optical 
counterpart. Thanks to SWIFT ( and also HETE satellite ) it was also possible 
to observe the first optical counterparts of the short GRBs which were previously 
undetected. These counterparts were localized in the old elliptical galaxies which 
strongly supports merger scenario expected to occur in old binary systems. There 
is currently handful of long GRBs for which optical counterpart was observed 
during the GRB itself, the earliest and most bright are listed in Table 11.21 



GRB 


Telescope 


Reaction 
Time fsec] 


Max 

Magnitude 


Description 


990123 


ROTSE [19] 


25 


9 


Optical light curve un- 
correlated with 7 light 
curve 


041219A 


RAPTOR [22] 


1151 


18.6 


Optical light curve 
correlated with 7 light 
curve, triggered by 
precursor 


060111B 


TAROT [23] 


30 


13.75 




061007A 


ROTSE 


26.4 


13.6 




060904B 


TAROT 


23.1 


15.8 




051111A 


ROTSE 


26.9 


13 





Table 1.2: Observations of optical light curves of GRBs during the 7 emission 



The light curves of these events have different properties. For example the 
optical light curve of GRB990123 has no clear correlation with the gamma emis- 
sion while light curve of GRB041219 is apparently correlated with the gamma 
emission ( Fig. 11.61 ). 

This suggests that the optical emission mechanism can be different in these 
two bursts. In the first case it is believed to be caused by back propagating 
reverse shock on the ISM ( external shock ). In the second case it is believed 
to be caused by the same mechanism as 7-ray emission i.e. internal shocks. 

^GRB 041219a was a very long GRB Tgo w 520 sec, Tgg is a time when 90% of fluence was 
detected 



Moreover there are models suggesting that in some cases optical emission may 



precede the 7-ray signal or can even be stronger [2J|. More early data is needed to 
resolve these doubts. Current experiments have very limited chances to observe 
GRB in the optical band during 7-ray emission, because time delay due to trigger 
propagation and pointing of the telescope in best cases limits the reaction time to 
30-40 seconds. Another limitation of current experiments is the time resolution, 
only few ground base telescopes perform observations with a time resolution of 
the order of seconds. An experiment observing full FoV of the satellite with a 
temporal resolution on the level of seconds would greatly contribute to resolving 



the GRB puzzle 2J|. The "Pi of the Sky" experiment is planned to realize exactly 



this type of strategy and observe GRBs in optical bands during the 7 emission. 
1.0.2.1 The GLAST satellite 

The Gamma Ray Large Area Space Telescope ( GLAST ) mission is planned to 
be launched in the beginning of 2008. GLAST is a next generation high-energy 
gamma-ray observatory designed for making observations of celestial gamma-ray 
sources in the energy band extending from 10 MeV to more than 100 GeV. It 
follows in the footsteps of the CGRO-EGRET experiment, which was operational 
between 1991 and 1999. The sensitivity of detectors have been greatly improved 
comparing to EGRET detector on-board the CGRO satellite. The main objective 
of the mission concerning the Gamma Ray Bursts is to determine their behavior at 
high energy. The GLAST Burst Monitor (GBM) detector observing the FOV~10 
steradians in energy range 5keV-30MeV will allow for fast identification of the 
burst and determination of its position with accuracy of a few degrees within 1 
second [25|. The Large Area Detector (LAT) allows to study behavior of GRBs 
at higher energies in the wide energy range 20 MeV to 300 GeV, it has FOV~2.5 
steradians. It will also allow to determine the GRB position with the accuracy 
of ~ 10 arcmin. The strategy is very similar to the SWIFT's one, in case GRB is 
detected by GBM , but outside LAT's FOV, the GBM position is used to reorient 
the spacecraft, so that the burst position is within the FOV of the LAT detector. 
Bursts alerts will be sent to GCN network within 10 seconds ( [^l )• It is 
expected that the GLAST satellite will detect ~ 200 bursts/year. 



1.0.3 Orphan afterglows 



The jet structure of GRB explosions was originally proposed to resolve the prob- 
lem of huge energies ( 10^^ erg ) resulting from cosmological distances to GRBs. 
There is now extensive observational evidence for such collimated emission from 
GRBs, provided by breaks in the optical/IR light curves of their afterglows ( [2^, 
29l |. [30| )■ Examples of light curves with observed "jet breaks" are shown in 



Fig. ll.lOi This effect is related to relativistic beaming effect, radiation isotrop- 
ically emitted by relativistic matter becomes collimated. Thus, only radiation 
emitted by the small part of the jet is visible from the Earth. When matter 
reaches the Interstellar Medium ( ISM ) it is slowed down, T factor decreases 
and collimation becomes smaller, allowing observation of lower energy radiation 
emitted from other parts of the jet. Finally matter is slowed down so much that 
collimation is of order of the jet opening angle 6 jet- Since this moment observer 
can detect radiation emitted from all parts of the cone ( [3ll| , [32| )■ This causes 
smaller energy fluxes observed from the Earth because the radiation is no longer 
collimated and is emitted more isotropically. Collimated structure of GRB ex- 
plosions implies that only small fraction of the total number of all GRBs in the 
Universe can be observed from the Earth. Since radiation emitted in late times 
is observed in optical band, it is expected that more optical afterglows should be 
observed then the GRBs. Such kind of afterglows without GRB event are called 
"orphan afterglows". They would appear as optical flashes without correspond- 
ing 7-ray detection. Observation of such events would allow for further tests of 
the GRB collimation hypothesis ( [33| , |3j| ). The typical orphan afterglow 
is rather related to late times, however the similar situation may occur during 
prompt optical emission. This can be due to early external shock ( GRB990123 
), reverse internal shocks or internal energetic structure of the jet ([35|). Such 
scenarios would lead to smaller collimation of optical emission, which would lead 
to possibility of finding optical flashes related to GRBs with similar timescale, 
but without corresponding 7 detection mbox( [35|| , [32|). Another possibility of 
flnding optical flashes without corresponding gamma detection is the failed GRB 
scenario ( [32| )• Observations of these kind of events would greatly improved 
understanding of the GRB emission properties and geometry. The recent analysis 



lan afterglow events and no confirmed 



37| )• In order to observe such kind 



give only limitations on the number of orp 
event of this kind was observed ( [36|| , 
of events a wide field monitoring system is needed. One of the main results of 
this thesis is determination of limits on the number of prompt orphan afterglow 
events on the whole celestial sphere and on the ratio of optical and 7-ray emission 
collimation. 
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Figure 1.9: The mechanism of the jet break caused by slow down of relativistic matter on the 
ISM (image from 0). 



1.0.4 Other fast astrophysical processes 

Beside described in detail GRBs there is a variety of other astrophysical processes 
manifesting themselves in time scales from seconds to days. It is impossible to 
describe all of them in detail, however a short description of those which can be 
observed with the "Pi of the Sky " apparatus will be given : 

• Nova explosions - these processes occur in binary systems with white 
dwarf accreting matter from a companion star. The matter accumulates 




time (day) 



Figure 1.10: Optical light-curves for 10 GRB afterglows with breaks and power-law fits to the 
pre- and post-break emission ( image taken from [7| ) 



on the surface of the white dwarf and when certain critical mass is reached 
a thermonuclear explosion occurs. This process may repeat when enough 
matter is accreted again, these kind of novae are called recurrent novae. A 
very comprehensive introduction to subject of novae explosions is given in 



38l |. Depending on the range of the telescope novae explosions signature is 
a sudden increase of brightness of the system or appearance of a new object 
( in case normally it is below limiting magnitude of the telescope ). 

Variable stars - about 1% of all stars are variable stars. The time scale 
of brightness variations ranges from years and days down to milliseconds. 
The variability mechanisms can be geometrical configuration ( e.g. eclipsing 
binaries ) or internal properties of the star ( e.g. pulsations ). A particular 
type of variable stars are fiare stars ( also known as UV Ceti variables ), 
which undergo sudden and unpredictable explosions related to release of 
magnetic energy. The mechanism is the same as in the case of Solar flares, 
however, flare stars explosions can be even thousand times brighter. The 



brightness increase can be as large as 100-1000 times. The variability in the 
flare stars is characterized as a rapid, irregular large-amplitude increase of 
brightness, followed by a much slower decay ( from minutes to hours ). 

• AGNs and particularly blasars - these objects are active galactic nuclei 
which are powered by accretion of matter on central super massive black 
hole. In many cases a jet of relativistic matter is observed, which is most 
probably ejected in the direction of spin of the black hole. If the jet is point- 
ing towards the Earth, such AGN is called a blasar. AGNs manifest rapid ( 
time scales of days or even hours ) brightness variations in all wavelengths. 
Monitoring of such objects and alerting about the increase of their activity 
is very important for observations by big telescopes and can be realized by 
small wide field telescopes. 

• Supernovae - these processes are related to death of massive stars. When 
the thermonuclear reactions in the core are not able to balance gravitational 
pressure the star collapses and a huge explosion occurs ( Esn ~ 10^^ erg 
). There are over 400 extragalactic supernovae discovered per year, which 
means they are very dim and mostly below the range of the telescopes like 
"Pi of the Sky". However, the brightest could also be discovered by a system 
like this. 

The above list is just an indication of what kind of processes are the aim of 
analysis described in this thesis. In most cases the main goal of the analysis is 
a discovery of an object and sending alert to larger telescopes as the "Pi of the 
sky" system is not able of performing spectroscopic measurements. However, in 
many cases good time resolution of the system gives a possibility of investigating 
brightness variations in time. 



Chapter 2 

The Pi of the Sky Experiment 



2.1 General Idea 

In order to study rapidly varying astrophysical objects a telescope with time 
scale resolution at least of the order of seconds is needed. Exposures and dead 
time between images must be short. This will allow to investigate light curve 
structure of rapidly varying objects. However, this is not enough to study short 
and unpredictable processes like optical flashes related to GRB or any other kind 
of optical flashes. In such cases it is impossible to predict where and when an 
event will occur. Thus, it is not possible to point the telescope at certain star and 
wait for an event to occur. In order to be able to observe such class of processes 
when they are going on a large field of view (FOV) is required. If the telescope 
system will observe the whole sky continuously, then any outburst will already 
be in its FOV. There will be no delay, due to telescope movement and trigger 
information distribution. The area of interest will be observed continuously. The 
price for this is the range. The more sky a telescope observes the less sensitive it 
is to faint objects. 

p ■ N 

ruMAX = mo + 5 ■ W{ . ^ . ^^^ 1 (2.1) 

Where mo is limiting magnitude of telescope with given detector and aperture 
of 1cm, p is pixel size in /im, N is chip size in pixels, S is light power and FOV is 
field of view in degrees. For human eye detector mo = 7.5"^ and using F0V=21° 
^MAX ~ 11.8*" which is close to limiting magnitude of camera with Cannon 
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f=85mm f/D=1.2. However, for precise result mo should be determined from the 
specific CCD camera properties. It can be clearly seen that limiting magnitude 
decreases with field of view. One needs to find a compromise between FOV of the 
single telescope and the maximum limiting magnitude it will be able to observe. 
It is of course impossible to build a single camera which would cover the whole 
celestial sphere at once with satisfying limiting magnitude. The solution for this 
is to build a system of many telescopes, each covering a fraction of the sky and 
pointing to different direction. The range of such a system will be limited by the 
range of a single telescope. In principle it would be possible to build a farm of 
large telescopes with high limiting magnitude, but the cost would be huge. One 
has to find another compromise between limiting magnitude ( number and size 
of telescopes ) and the cost. The "Pi of the Sky" system was designed to cover 
significant fraction of the sky with the satisfying limiting magnitude on the level 
of 14-15™. Data analysis presented in this thesis was performed on data collected 
by the prototype of the full system. In the next section this prototype will be 
described in detail. The full detector design will be presented in Section [2731 

2.2 The Prototype 

The prototype was build to test components of the final system including hard- 
ware and software solutions. One of the goals was to probe efficiency of optical 
flashes detection and background rejection. The prototype was installed in June 
2004 in the Las Campanas Observatory (LCO) in Chile and it is working until 
now with a few months break. The prototype after upgrade is shown in Figure 
12. 1[ The system in LCO operates automatically and is fully controllable via the 
Internet. There is no person in LCO who takes care of the system. It is very 
important requirement for both the prototype and the full system that it must be 
remotely controlled and failure proof. The current setup of the prototype allows 
even some of the hardware failures to be handled remotely and continue opera- 
tion of the detector. The maintenance trips to LCO are expensive so the need 
for them must be minimized. Current experience says that one maintenance trip 
a year should be enough. 
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Figure 2.1: The prototype in LCO, two cameras on a single mount in the ASAS dome 



2.2 The Prototype 



2.2.1 Hardware 

The detector consists of two cameras on a single paralactic mount ( Fig. 12.11 ). 
The mount was adopted from the AS AS experiment. It is driven in two axis 
by step motors. The TMCM 300 microcontroller driver by Trinamic was used 
to control mount from the PC [39fl. The microcontroller box is connected to 
the PC with the RS-232 interface. On the PC side the mount driver program 
controls settings and movements of the mount. The position of the mount can be 
calculated from number of steps executed by the step motors. The resolution of 
step motors is AA ~ 3.5" and A6 ~112.5", where (A, 5) are equatorial coordinates 
right ascension and declination. As a cross-check potentiometers were added, 
they give rough estimate of the position with the accuracy of Aa ~ 0.2° , this 
allows to detect step motors position errors ( for example due to slip of belt drive 
). During observations mount performs tracking which is a rotation around the 
Earth axis compensating for the Earth daily rotation. 

The cameras are custom designed. The development of own CCD cameras was 
motivated by several reasons. The first factor is the price of commercial products 
available on the market. However, there are other reasons which limit possibility 
of using commercial products in such kind of remotely controlled experiment : 

• reliability of internal mechanical shutter 

• remote control of camera settings which include lens heating and lens focus 
adjustments 

• temperature and humidity sensors 

• fast readout ( in most of the solutions limited to IMHz ) 

• possibility of changing firmware of the camera remotely 



The cameras are based on Fairchild CCD 442A chip [40|| with resolution 
2048x2048 pixels ( 15 /i xl5 /i each ). The CCD sensor is placed in a separate 
chamber filled with a noble gas. The 16bit analog digital converter (AD9826) has 
been used. Communication with the PC is realized by USB2.0 interface by the 
Cypress FX2 USB CYC68013 chip. Camera is controlled by the FPGA Altera 
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chip. CCD chips are cooled with the thermoelectric Peltier junction, down to 30° 
C below ambient temperature. The following features have been implemented in 
cameras : 

• Remote control of almost all functions : readout frequency, gain, CCD tem- 
perature, mechanical shutter, lens focus regulation, lens heating ( against 
water condensation ) 

• Remote monitoring of atmospheric conditions ( temperature and humidity 

sensors ) 

• Possibility of remote firmware upgrade ( Cypress microcontroller program 
and FPGA configuration ) 

• Watchdog Timer which resets camera in case communication with PC is 
lost 

The table below summarizes the parameters of the cameras : 



Parameter 


Value 


Readout Time 
Readout noise 
Shutter Durability 
USB2.0 max transfer speed 
Maximal cooling 


Is - Imin 

<16e- at 2MHz and <12e- at IMHz 
>10'^ cycles 
52MB/S 
30° below ambient temperature 



Table 2.1: CCD cameras parameters 



More details on design of the cameras can be found in [4ll|- The cameras are 
equipped with CANON EF f=85, f/d=1.2 lenses. Short time exposures (5-10 
sec) imply many (~ 2000 — 4000) exposures during a single night. This results in 
^ 10^ images per year. Huge number of collected images required special design 
of the shutter which can survive more then million cycles ( commercial shutters 
usually work up to 10^ cycles ). In order to save shutter it is possible to make 
exposures with shutter permanently opened. The mount with cameras is installed 
in the AS AS 42|| dome in the LCO ( Fig. 12.21 ). The dome is controlled by the 
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OGLE telescope system (|43|). It opens when the OGLE telescope dome opens, 
which depends on observer's decision motivated by the weather conditions. The 
mount and the cameras are controlled by the single PC computer which is placed 
in the lower part of the dome (Fig. 12. 3p . Custom driver was developed to control 
parameters of the cameras and collect images, it will be described in the next 
section. The system contains two other PC computers which are used for off-line 
data analysis. 




Figure 2.2: Dome of the ASAS experiment in LCO 



2.2.2 Software 

2.2.2.1 Overview of the system components 

The main "Pi of the Sky" software components are running under Linux (Fe- 
dora) operating system. Most of the software used in the experiment was custom 
developed. Some of the procedures and formats were adopted from the ASAS 
experiment [42|. Generally software can be divided into on-line part, which takes 



care of detector control during nightly data acquisition and off-line part which 
performs off-line data analysis. 
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Figure 2.3: Pi2 computer controlling nightly data acquisition is located in the lower part of the 
ASAS dome 



General architecture of the night control system is presented in Figure 12.41 
The system consists of several modules which communicate with each other by 
the CORBA interface 4j|. They were designed in the client server architecture. 



The main components of the system are : 



• PIMAN 

It is the main manager program which controls the whole system. This pro- 
gram provides set of commands which can be executed by different modules. 
There are also complex commands, which use several different modules. In 
this case result of command executed by one module is used as an input 
to command for another module. Commands can be executed manually 
from pishell program or loaded in form of the pish script by runscript 
program. Example of the night script is given in Figure lA.Si It is a set of 
commands with times at which they should be executed. Script is gener- 
ated every evening by the genscript program. After system is started the 
runscript program is executed to read the night script and sent it to the 
piman program. The piman program executes commands at specified times. 
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EXTERNAL GCN SERVER 



Distributs alerts about GRBs to 
registered experiments 




GCN MODULE 



Receives alerts and satellites pointing 
information from GCN sen/er 



DAO MODULE 

Controlls the cameras, 
collects images and 
perfomers on-line algorithm 



Pi-Manager program controlling 
of other modules. It executes night script 



MOUNT MODULE 



Controlls functionality 
of the mount 



\7 



/\ 



Allows for sending commands to 
piman in interactive mode 



RUNSCRIPT 
Reads night script files and loads it to piman 




GENSCRIPT 

Generates pish script 
programming the system 
work for current night 



PISH SCRIPT FILE 

# auto-generated script 

# night 20070315 

# camera : Cannon EOS f=85mm 

piman 1 exec_script_synchro(startup.pish) 

daq 1 845 start_daq 

interna! 1900 forced_point_best_target 



Figure 2.4: General architecture of system controlling the detector during nightly data acqui- 
sition implemented in the prototype 
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In case GCN alert is received by the GCN module the alert information is 
passed to piman and handled ( See. I2.2.2.7I ). 

• PISHELL 

This pishell program is a client program which has interactive command 
line interface. User can launch this program to sent commands to piman in 
interactive mode. It allows modification of night scheduled program loaded 
from the pish script. All necessary actions like checking stack of commands, 
deleting commands and adding new commands can be executed by using 
this program. 

• RUNSCRIPT 

This is a simple client program for reading given pish script and sending 
it to piman module. 

• DAQ 

This program is responsible for controlling cameras settings, collecting im- 
ages and on-line data analysis. On-line data analysis consists of two main 
actions : astrometry and flash recognition algorithm. In general astrom- 
etry is a transformation of chip (x,y) to celestial (A, 5) coordinates. This 
transformation allows to calculate coordinates of image center. They can be 
compared with the expected coordinates and mount movement corrections 
can be determined. On-line flash recognition algorithm looks for optical 
flashes in single 10 sec exposures. More detailed description of the DAQ 
module will be given in the next section. 

• MOUNT 

This module is responsible for controlling the mount. All functionality 
of the mount hardware can be controlled by this program. This includes 
calibration, moves to the desired position, enabling/disabling of tracking, 
changing the tracking speeds and calibration of the pointing using exact 
information from astrometry ( DAQ module ) or encoders ( potentiometers 
in the prototype ). The core of this module is compiled in form of library 
libmount .so. There are two programs using this library. Program monit 
allows to control the mount in the interactive mode, while mount_server is 
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a server which provides a set of functions which can be executed by piman 
when performing commands from a night script. 

• GCN This module is waiting for GCN alert messages sent through soft- 
ware sockeJl] from the remote GCN server (Fig. 11.71) . During the night every 
package obtained from the GCN server is passed to piman module which 
decides weather it is an interesting event which is possible to be observed by 
the "Pi of the Sky" system. In such case alert procedure is executed (Sec. 
12.2.2.71) . The gen module is also responsible for writing satellite pointing in- 
formation to log files ( swift_pointdir.log and integral_pointdir.log 
). This information is used by pointing procedure to follow FOV of the 
GRB detecting satellites (Sec. 12.2.2.71) . 

• GENSCRIPT This program is responsible for preparing a plan of night 
observations. It is generated in form of pish script (Appendix lA. 51 ) which 
is loaded to the piman program memory and executed during the night. 
The syntax of the single command is the following : 

MODULE TIME COMMAND ( command parameters ) 
The module name internal is used for complex commands ( see above ). 
More detailed description of the script generator module will be given in 
separate subsection 12.2.2.71 

Every module writes its current status to the specified status file. They also 
produce separate log files and most important information is saved to global "Pi 
of the Sky" system log file (Tab. IA.4I) . The relations between "Pi" modules and 
external systems are presented in Figure 12.41 Communication between modules 



is client-server architecture and is implemented in CORBA technology |4j| which 
is efficient and reliable method of object oriented interprocess communication. 
Most of modules were written in C++ and C. 

2.2.2.2 Data Acquisition System 

The data acquisition system (DAQ) is a program which is responsible for collecting 
images from the cameras and for on-line data analysis. The program uses sev- 



^ socket - term for type of interprocess communication 
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eral custom developed libraries which provide different functionality. The most 
important libraries are listed in Table lA.ll in Appendix lA.li 

This libraries are linked by several programs, the most important programs 
for data collection and analysis are listed in Table IA.2[ Programs which are used 
every night for data acquisition are ccdsingle and ccddouble. The first one 
is used when DAC) uses single camera to collect data. The program ccddouble is 
used to collect images from 2 cameras on the same mount working in coincidence. 
The main parts of the collection program are shown in Figure 12.51 The only dif- 
ference in ccdsingle program is that images are collected from single camera 
and the algorithm for flash recognition is different. 

The most important task of these programs is to collect images from the cam- 
eras and save them to a disk. There are also actions important for other modules 
in the system, the most important one is astrometry (Sec. I3.3.1.ip . Generally 
astrometry is a procedure for transforming (x,y) coordinates of objects on CCD 
chip to equatorial coordinates (A, 5). More details on astrometry procedure can 
be found in Section I3.3.1.1[ Astrometry is very important for finding real coordi- 
nates of image center which can be slightly different then values calculated from 
mount step motors. The position of the image center found by astrometry can 
be verified against position calculated by the mount module. In case they differ, 
position determined from astrometry can be used to correct mount position and 
also mount tracking speeds in both axis. The third main task of DAQ program 
is to analyze images in search for optical flashes (Sec. 13. 2p . Interesting flashes 
found by the algorithm are saved on disk and are almost immediately published 
on the WWW page in order to be reviewed by human. DAQ program exports 
several functions and acts as CORE A server (Appendix IA.4j) . This functions are 
executed by piman in order to control the whole system. Information from DAQ 
program is stored in night log file ( see Appendix IA.3I ) Most important infor- 
mation is stored in the database allowing for fast and easy access for reporting 
purposes (Sec. 12.2.2.51) . 
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Initialization of program paramters 
( from cfg files ) 

I 

Initialization of camera 
( settings and cooling ) 



3 for start jaq request from piman 
( if required ) 

After start daq request arrives DAQ enters collecting loop and remains ttiere untii 
ttie end on data collection ( exit request from piman ) 



After starl daq request, make darks if needed 
( in case cooling failed to cool to desired temperature 
the old dark from one of ttie previous nigfits villi be used ) 



Handle requests from piman if any were sent and 
added to request queue. Tfie request can be : 
■ change off collection mode to sky/dark or GCN trigger 
■ paramters modification 
■stop of data collection 

■ exit of daq program 

■ coordinates change 

etc... 



Take next image from driver ( call of GetNextFrame ) 

Images are collected in second thread. 
When image Is taken from collection thread, a request 
for next image is sent to collection thread in the same moment 



Check If new astrometry should be performed on new image 
( in case there was pointing change or time since last astrometry 
exceeded limit etc ) and execute astrometry if needed 



PIMAN MODULE 



A 



CC RBi . 



V 



DAQ Interface : 

listening for requests 
from PIMAN module 
and in case any is added 
it is inserted into request queue 



Image collecting thread 
When new image is requested from 
the main thread it Is send back and 

the next one is started 
Data collector is working in such a way 
that when new exposrure is being taken 
the previous one is transfered 
from camera to PC 



Analyse new image with the on-line flash recongition algorithm 
in case there are any interesting events found save them in log 
files and database table Events 



Figure 2.5: Block diagram of the Data AcQuisition program 
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2.2.2.3 System nightly performance 

The system is started every evening from crontatllby starting script run_pisys ! . 
This script waits until the dome is opened and then it launches all system modules 
like piman, DAQ, mount, gen etc. After all modules are started the night script is 
loaded to piman's memory and subsequent commands are executed at specified 
times. Since this moment the system can be controlled from the pishell. Af- 
ter DAQ is started communication with cameras is initialized and program waits 
until cameras are cooled to temperature specified in the configuration file. After 
cameras reach the desired temperature, program waits for command start_daq. 
This command is executed when dark images can be collected. Dark images are 
images collected in the same conditions as the sky images but with closed shut- 
ter. This allows to obtain average values of noise and dark current in every pixel. 
Before analysis of a the sky image the dark image is subtracted from it. Typically 
20 dark images are collected and median image is calculated to be used as a dark 
image in further analysis. After the dark image is ready, DAQ program is ready to 
collect sky images and waits for a command to start analysis. The piman module 
chooses the best object to be observed by launching point_best_target com- 
mand and sends request to mount module to move to the position of this target. 
The start_analysis command passes sky position obtained from mount module 
to DAQ, it is required to perform astrometry. Before any change of the position 
the DAQ stops collection of images, it is restarted after next start_analysis com- 
mand is obtained from piman after the desired position if reached. In specified 
time intervals piman asks DAQ for current position (A, 6) of image center resulting 
from astrometry and sends this information to mount in order to correct tracking 
speeds in both axis. Twice a night the whole sky scan is performed. During the 
scan DAQ takes images in single image mode without performing astrometry in 
order to complete the scan as fast as possible. Astrometry for scan images is 
performed off-line. 



^crontab is a system tool for starting programs at specified dates and times 
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2.2.2.4 Camera Driver 

The CCD cameras used in the project are custom designed. Due to this fact it was 
necessary to develop the software to control them. The camera driver was devel- 
oped in C/C++. The original cameras were equipped with USB2.0 interface only. 
The driver for USB2.0 cameras consists of two parts. The first part is a kernel 
module pikam.ko which can be compiled under Linux kernel > 2.6.5. The second 
part is the C++ class Device2K2K which opens the device file ( /dev/usb/pikamN 
) in order to communicate with the camera. The final design of the camera was 
enriched in gigabyte Ethernet interface. The Ethernet camera exports the same 
set of functionality, so only the low level communication part of the driver has 
to be optionally replaced. This required development of communication protocol 
NUDP |45|, it is implemented in camera firmware and in PC driver. Dedicated 



kernel module is not needed in this case. The C++ class CEthCamera using ex- 



ternal library Sockets \4^ implements communication with camera via Ethernet 
interface. The class DeviceEth2K2K derived from Device2K2K overwrites several 
low level communication functions using member class CEthCamera ( see Fig. 
12.61) . New Ethernet camera gives a possibility of using USB2.0 or Ethernet inter- 
face, depending on current user requirements. Change of communication can be 
easily done by editing configuration files or by command line option to the data 
acquisition program ( see Table [Al2] in Appendix lA.ll ). The driver is compiled 
in form of library libpimandrv.a. 



Images are saved to fits files (|47|,[48|). Writing of fits files is realized by 



library libmyf itslib . a, but this is the camera driver library which is responsible 
for preparing camera settings information to be saved in fits file header. The 
keywords related to camera settings are listed in Table IA.3I in Appendix lA.li 
Most of this information is also written to the database. The driver library is 
linked by DAQ programs (ccdsingle and ccddouble). The best way to easily test 
cameras is to use program test2K2K (Tab. IA.2I ). It is a simple text interface 
interactive program which allows to change settings of the camera, to take image 
and to realize any kind of camera functionality. It can be used to operate camera 
by the USB2.0 interface or by the Ethernet depending on options passed in the 
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DGviceBase 

Base class for all types 

of camera driver. 
Contains most common 
member variables and 
functions required by any 
type of camera driver 
( like : CCDTemp, Cooling, etc ... ) 

iwiost of the functions are virtual and 
are overwritten in derived classes 

s 

I 

I 

\ 

Device2K2K 

Class implementing driver for 2K2K 
camera ( k2 and k20 ) 
It opens /dev/usb/pikamN node 
to comunnicate with the camera 

It has member variables and functions 
specific for this kind of camera 

Some classes are virtual and are 
overwritten in the derived classes 

5 



DeviceEth2K2K 



Class derived from Device2K2K. Functions 
which are different for ethernet camera 
driver are overwritten here. 

The functionality of comunication with 
ethernet camera is realized by member 



CEthCamera *m_pEthCamera; 



CEthCamera 

Class implementing communication 

with ethernet camera driver. 
It implements sending commands and 

receiving answers. 
Also image transfer from camera is 
specially implemented here and 
error handling 

It has member variable : 

NudpSockef _comm; 

which implements NUDP protocol used 
to communicate with camera 



NudpSockef 

Class implementing NUDP protocol on the 
PC side which is used to communicate 

with the ethernet camera. 
NUDP protocol is also implemented in 
the camera 



Figure 2.6: Dependencies of camera driver C-I-+ classes 
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command line. It is also possible to use this program in a batch mode where 
actions to be performed are passed in the command line. 

2.2.2.5 Database for on-line data 

In order to store the most important information about system on-line per- 
formance a database structure was designed and developed. The PostgreSQL 



database system is used for this purpose |49|. The structure of the database used 



for storing on-line system information is shown in Figure [2771 DAQ program stores 
on-line information in 3 tables : 



• FRAME and FRAME_DET tables contain information about every 
image collected by the system. Generally all information from fits header 
is saved to the database, some additional information is also added. 

• EVENT stores information on interesting events detected by the on-line 
algorithm 

The other two tables are used for storing information from piman and mount 
modules : 

• PIMANCOMMAND stores information about commands executed by 
the piman program 

• MOUNTSPEED stores information about mount tracking speeds 

Second part of "Pi of the Sky" database is star catalog and will be described in 
details in Section 13.3.1.21 

2.2.2.6 DAQ configuration 

The DAQ can be configured by means of configuration files. Every parameter has a 
default value which is hard coded in the program code. In most cases this value is 
proper for typical system settings. However, the default value can be overwritten 
by values read from configuration files. The priority of loading configuration files 
is the following ( starting from the highest ) : 
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id_frm - internal record ID 
iframeno - night image number 
idaynight - night 
spathtofile - path to FITS tile 
icamid - camera ID 
scamfilter - filter 
inaxisi - X size 
inaxis2 - Y size 
sopbject - name of observed object 
fra - right ascension of image center [h] 
fdec - declination of image center [deg] 
ttime ut - unixtime of image start 
sloctime - local time string 
slocdate - local date string 
fhjd - image HJD 
istarcount - number of stars on image 
ifitssize - size of FITS file 
ra2000, dec2000, par_x_N, par_Y_N - astrometry paramters 
matchedstars - number of stars matched to reference stars 
shutter_mode - shutter mode ( opened / closing ) 
avg - average pixel value 
rms - RMS of pixel value distribution 
cat stars - number of reference stars on observed field 



id event - internal ID of record 
id frm - link to Frame record 
frame_no - frame number 
event_no - number of event on frame 
X - chip X coordinate 
y - chip Y coordinate 
lap_new - "laplace" value on new image 
lap_prev - "laplace" value on previous image 
lap_max_new - maximum value of laplce in cluster on new image 
s_raw - raw ADD value of event 
sphericity - value of shape indicator 
cluster_size - number of pixels in cluster 
black ratio - black pixel indicator 
coic_radius_sec - distance of conciding event on second camera [arcsec] 
ra - right ascension [deg] 
dec - declination [deg] 
evt_time - unix time of event 
evtpath - path to FITS sub renders 
mag - magnitude of flash 
evt_slt_ok - flag if TLT accepted the event 
evt_external - information on external triggers related to this event 
evt_night - night 
evt_online - if found on-line or off-line 
evt_runtype - algorithm type 0-coinc 10s,1-coinc sum 8, 3-single cam on-line 
conirmation on next, 4-off-line single, 5 - off-line coinc 10s 
lap_next - laplace value on next image 
evt_camid - camera ID 
evt_glon - galactic longitude 
evt_glat - galactic latitude 
evt_type - event type , 0-verified, 1-final,3 - singia cam, 4 - generated 
evt_slt_reason - reason why TLT rejected this event 
evt_min_dist_cone - minimal distance from Earth required for satellite to flash 



id frm - link to internal ID of FRAME record 
sobserved - name of observed 
ssoftware - version of software 
sbuild - build of software 
sdrvtype - driver version 
icamiidx - index of camera 
fexptime - exposition time 
frexptime - measured exposition time 
bshutter - shutter opened / closed ( DARK or SKY ) 
fadcgain - ADC gain value 
fadcbias - ADC bias setting 
fadcgset -ADC gain setting 
finagain - LNA gain setting 
fadcbset - ADC bias setting 
fadcrange - ADC range 
fadcclamp - adc clamping 
felecgain - electron gain 
bcooling - cooling on/off 
fabinn - analog binning 
fsbinn - software binning 
fspeed - chip readout speed ( setting ) 
sspeedmh - readout speed [Mhz] - string 

bmpp_bc - mpp mode on/off 
fro_time - USB/Ethernet transfer time [sec] 
fcrotime - chip readout time 
ifocus - focal lenght [mm] 
bhitlens - lens heating on/off 
ssavearea - image save area [string] 

susbmode - USB mode used 
sfpgver - version of FPGA software 
scprsver - version of Cypress software 
sverdesc - version description 
frnoise - readout noise [ADU] 
frelnoise - readout noise [in electrons] 
fchiptset - required chip temperature 
fchiptemp - actual chip temperature 
fcasetemp - case temperature 
fambtemp - ambient temperature 
fcamhumid - humidity 
fambhumid - ambient humidity 
fintrtemp - ???? 
fairmass - airmass 



MountSpeed 



ms_id - internal ID of record 
ms_time - unixtime of speed information 
ms_omega_ha - angular speed in HA axis [ ??? ] 
ms_omega_dec - angular speed in DEC axis [ ??? ] 



PimanCommand 



pmc_name - name of piman command [ string ] 

pmc_param1 - first paramters of command 
pmc_param2 - second parameter of command 
pmc_time - unixtime of command 
pmc_night - night 
pmc moduie - module to which command was adressed 
pmc_par1 - param 1 
pmc_par2 - param 2 
pmc_par3 - param 3 
pmc_par4 - param 4 
pmc_par5 - param 5 
pmc_par6 - param 6 
pmc_par7 - param 7 
pmc parS - param 8 
pmc_pimanid - ID of piman program 



Figure 2.7: Structure of database for storing on-line information from the system 
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• Some parameters may be overwritten by the options passed to the program 
from the command line 

• Program looks for file ccd . cf g in the directory where it was started ( current 
directory ). In case it is found the settings from this configuration file are 
loaded. 

• In case local ccd.cfg file is not found, program looks for global configura- 
tion file $NDIR/cfg/ccd.cfg and if found loads settings from this file 

In case non of the ccd. cfg files is found the default values defined in program 
code are used. They may not be optimal for current system configuration so 
specific ccd.cfg file should be provided and required parameter values should 
be placed there. It is possible to change values of parameters during the data 
collection by executing command change _par am from pishell program ( Tab. 

2.2.2.7 Observation Strategy 

The experiment is mainly devoted to optical fiashes related to GRB, thus observa- 
tion planing depends on pointing direction of GRB detecting satellites. The final 
version of the detector covering 2 steradians will cover FOV of the SWIFT BAT 
or GLAST LAT detector and pointing of cameras will depend on pointing direc- 
tion of these satellites. In the case of the prototype, FOV is much smaller, but 
observation strategy is very similar. The system tries to point the cameras to the 
center of FOV of one of the satellites which are capable of determining the burst 
position. Before June 2006 the primary targets were HETE and INTEGRAL, af- 
ter this date the highest priority target is SWIFT satellite. The observation plan 
is generated automatically in form of pish script (Appendix lA.Sp . Currently the 
telescope pointing is performed dynamically. Pointing information is obtained 
from GCN server through the software socket during the system operation and it 
is used to point the telescope. The piman program executes pointing command 
every half an hour. It calls procedure which finds the best target to be observed. 
The best target is chosen from list of targets sorted in order of priority, every 
target is checked and in case it satisfies several constraints : 
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• h > 28° 

• distance from the Moon > 30° 

it is chosen as the best target. The primary target is SWIFT, secondary target 
is INTEGRAL and next targets are objects from the list of interesting astrophysi- 
cal objects (Tab. IA.6I ) Uke blasars, AGNs etc. The hst was compiled mainly from 



list of interesting objects used by Global Telescope Network (GTN) [50|- In case 
none of the targets on the list can be observed as the reserve target the field on 
the East (closest to (az,h) = (90°,28°) position) is chosen to ensure the longest ob- 
servation time. Always when new position of SWIFT is sent via software socket 
the piman program executes re-pointing procedure immediately after finishing 
the current exposure. In order to optimize photometry, the telescope does not 
observe arbitrary positions. Instead it finds closest field from the predefined list 
and telescope points to the center of this field. In this way each star is usually 
measured almost in the same position of the CCD chip. The above pointing pro- 
cedure is performed during most of the night. Twice a night the whole sky scan 
is performed by the system to cover all sky, which takes about 2x1 hour. The 
normal observation strategy described above can be interrupted on receiving the 
GCN alert about GRB with known position. When GCN module receives this 
kind of alert it sends it to piman module. In case the event can be observed ( it 
is above the horizon ) the normal program is postponed and system points the 
cameras towards the burst position. After half an hour systems returns to the 
normal observation plan. 

2.2.2.8 Remote system control 

The "Pi of the Sky" prototype is installed in LCO and full detector will also be 
installed in a remote location. This imposes specific requirements for the system. 
The most important one is failure-free hardware. Another obvious requirement 
is that the system must be controllable via the Internet. Most of the system 
functionality can be controlled via the ssh protocol by logging to remote host 
and executing programs. However, nightly operation control does not require 
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logging to remote host, most important information about the system perfor- 
mance is copied to local machines and is available by the WWW interface. This 
information is basically : 

• Database records from on-line tables containing information about images 
and results from the on-line algorithm ( Sec. 12.2.2.51 ) 

• Status files of all system components 

• Log files of most crucial system components 

• Parts of images containing events found by the on-line algorithm 

• Some of collected sky images ( converted to jpg format ) 

Under normal conditions the system does not require human attention, all jobs 
to be performed are started automatically from crontab. At given time night 
observation script is generated, configuration files and data folders are prepared, 
system is started and it runs until morning. The person on duty does not have to 
watch the system for the whole night. In order to warn about system problems 
special alert system was designed. In case status file from any module is not up- 
dated for long time or contains information about problems, e-mail or SMS is sent 
to person on duty. In such case probably human reaction will be necessary and 
will require logging to system controlling computer. The action would depend on 
the type of the problem, sometimes it is enough to execute piman command from 
pishell or restart one of the modules, while in case of mount server problems 
calibration procedure may be required. 



2.3 Full Pi of the Sky detector 
2.3.1 General Idea 

The full version of the detector is currently under construction. The final system 
will consist of 2 sets of 16 cameras. Each camera will cover 20° x 20° FOV, re- 
sulting in 2 steradians coverage of each set. The FOV of 2 steradians corresponds 



to FOV of the BAT detector on board of the SWIFT satellite ([5l|, [521) , it also 
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matches FOV of the LAT detector on the GLAST satelhte (|27||, [53|), which will 
be lunched in the beginning of 2008. These two sets will be installed in different 
places separated by distance of ~ 100 km. This separation distance will allow to 
reject optical flashes caused by near Earth objects ( mostly satellites), using the 
parallax effect. The stereo observations have already been tested in LCO (see 
Sec. 13.2.21) . The parallax will allow to reject near Earth flashing objects up to 
orbit of the Moon. 



2.3.2 Mounts 

The mount design was based on the mount used in the prototype, but it was 
redesigned and improved (Fig. 12. Sp . In the new design 4 cameras are installed 
on a single mount. They can work in two modes so called wide and deep. During 
normal operation cameras will work in the wide mode, looking at neighboring 
flelds in the sky and covering FOV~ 40° x 40° ( single mount ). In order to 
obtain higher limiting magnitude and improve precision of the photometry all 
cameras on the mount can be pointed to the same position in the so called deep 
mode. This strategy can be used in case of GCN alert about GRB when it is 
important to increase the range of the system by averaging many images of same 
field from different cameras. 

Hardware improvements in the mount design include also usage of harmonic drives 
to improve pointing precision. Better control of the position will be provided by 
13 bit encoders which will be used instead of potentiometers. New design of the 
mounts includes changes in the control system. New mounts will be controlled 
via the Controller Area Network (CAN) interface. In order to ensure fiexibility, 
CAN to Ethernet converters will be used and all commands from PC computer 
will be passed through the Ethernet interface. This allows much more fiexible 
system, where every mount obtains IP address and can be controlled by any PC 
computer in the cluster. The system schematic is shown in Figure 12. 9[ 



2.3.3 Cameras 

Some improvements were also introduced in the final design of cameras. The 
major change is the Ethernet interface, which was added to decouple cameras 
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Figure 2.8: Design of new mount for full "Pi of the Sky" system (upper plot) and fully assembled 
mount in reality (lower plot) 
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from the dedicated computer. The major disadvantage of the USB2.0 interface 
used in the prototype cameras was that they had to be connected directly to 
the controlUng PC computer. In case of the computer crash there was no way 
to use cameras until computer was repaired or replaced. This is not a problem 
in the case of the Ethernet interface, since the cameras can be connected to 
Ethernet switch and be part of local area network. In this configuration they 
can be controlled from any PC in the local network ( Fig. 12.91 ). This ensures 
that crash of a single computer will not make any camera unusable. The second 
major modification was the choice of the STA0820 CCD chip. There were also 
minor improvements. Stack of Peltier junctions was used to cool cameras down 
to 40° C below ambient temperature. Lifetime of the shutter was also increased 
by special breaking algorithm implemented in electronic which reduces the shock 
caused by the shutter opening and closing. 

2.3.4 Computer Cluster 

As it was described above the final system will consist of two sites with 4 mounts, 
each carrying 4 cameras. It was established during tests of the prototype that 
data collection and analysis requires about 1 CPU per camera. This allows for 
data collection and on-line analysis during a night and off^-line data reduction and 
analysis during a day. This implies that each set of cameras requires 16 CPUs 
to handle the system and data analysis. Instead of 16 computers, 4 machines 
with four core architecture will be used. In any case they will form a cluster 
of computers, which must be efficiently managed. The system architecture is 
presented in Figure 12. 9[ The main idea of this cluster is that none computer is 
unique and in case any of the machines crashes the system must remain fully 
functional and other PC will take over the tasks of the crashed computer. 



2.3 Full Pi of the Sky detector 



' current prototype of FulLPI system 




one site 



DNS virtual switch 



» 48-port Ethernet 



00Mb ^\ivitch 



router 

(www, SNMP7, VPN?) 



— 

1x 




router backup A 

(standby) ^ 



subnet 1 



1x 



subnet 2 



9x 



manageable, additicnal switifinert to 

HlxDOME? \[_ 

Mx weather station 
+12xlPMI(l)? 

, V over IP J ^ 

Power 



(^KVM / ip^j^'ower controT\ 
KVM switch 




1x 



( [p/seria] ) 



GPS 



(M<VM»JXL Ky^^.*)--^ KVM*;} catculatiori \J/ CantennaS 



CORBA 
DB postgres 



Intel IPMI v>1.5 



master 




master 




master 


(super piman. 






GCN, NTP, 
PISHELL) ^ 






backup 






backup 












slave 






slave 






slave 


(piman. 






(piman, 






(piman. 


daq, mount) 






daq, mount) 






daq, mount) 


• 






• 









12x eth + n USB 



pwi , default: on 



12x 



cluster 
12x PC 

3x master 
9x slave 

either night: 
4x for each 
mount 
5x online 
analize 
or day: 
9-12X offline, 
analize 



1x; 



>2x 2'4-port 1GB Ethernet switch 4 3^ 



USBTTPtonverter? switch? 

3m(low) /5m(full speed) cable length 

|7-port USB hub (active) 




Stand-alone cameras/mountfsl simulators, distance between mount s: 1 m 
Figure 2.9: Design of the full "Pi of the Sky" system 



Chapter 3 
Data Analysis 



Data analysis in the "Pi of the Sky" experiment consists of on-line and off-line 
parts. The on-line data analysis is required to control performance of the detector, 
but it is also responsible for finding optical flashes in timescale 10 or 22 sec in 
real time. Fast identification of optical fiashes gives a possibility to distribute 
alerts in the community for follow-up observations. The off-line data analysis 
acts on the reduced data. The reduction pipeline consists of three main stages 
: photometry, astrometry and cataloging to the database. Final, reduced data 
consists of star brightness measurements stored in the database, which provides 
easy and effective access. Off-line analysis algorithms act on the database, there 
are several algorithms developed for different purposes. In this thesis two off- 
line algorithms implemented by author will be described in detail. These are 
fiare recognition algorithm, looking for brightness increase of existing stars and 
algorithm for finding new objects in the sky. The database provides easy data 
access for broad spectrum of data analysis. Except algorithr ns p resented in this 
thesis there are also other ofi'-line algorithms implemented ( [5J|, [55|| ). 



3.1 On-line data reduction 



On-line data analysis is required for detector control. The most important task is 
astrometry, it is a transformation of chip coordinates (x,y) to celestial coordinates 
(A, 5) : 
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T:ix,y)^{\,5) (3.1) 
In order to obtain this transformation the following steps are performed : 

• Fast image reduction - subtraction of dark image ( this is step is also re- 
quired by on-line analysis algorithm ) 

• Photometry - identification of stars in an image and determination of in- 
strumental magnitudes and chip coordinates (x,y) 

• Astrometry - determination of non-linear transformation T:(x,y) — (A, 5) 
It is iterational minimization procedure comparing stars identified in the 
image by photometry with reference stars from external star catalog. This 
procedure will be described in more detail in Section 13.3.1.11 

After finding astrometry transform it is possible to calculate celestial coordinates 
of any object on an image from its (x,y) coordinates. The (A, 6) coordinates 
of image center are calculated and compared against the expected position and 
can be used to correct mount tracking speeds ( so called autoguiding procedure 
). Before analyzing an image with on-line algorithm fast image processing is 
performed. The first step is dark image subtraction. In the next step, image 
is transformed by special transformation called laplacJl. Value of each pixel 
is calculated as simple function of several surrounding pixels. Values in pixels 
just around transformed pixels are summed and values in other pixels far from 
it are subtracted. The idea of this transformation is to calculate simple aperture 
brightness for every pixel. 

Several types of filters which were tested are shown in Figure 13.11 Images 
before and after applying the g54 laplace filter ( aperture 4 in Fig. 13.11 ) are 
shown in Figure 13.21 it can be clearly seen that stars are sharper on the filtered 
image. Finally, one filter was chosen according to lowest ratio of <Jg/gavg value 
calculated for faint stars, where gavg denotes average of maximum laplace value 
for given star and ag stands for its dispersion. For old prototype version with 



^because it resembles a discrete version of Laplace operator 
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Figure 3.1: Different laplace types tested in on-line flash recognition algorithms 



Carl Zeiss f=50mm lenses laplace 4 (g54) was used and for the Canon f=85mm 
laplace 12 is used. On-line algorithm is based on transformed images, distribu- 
tion of pixel values after such transformation is centered around zero ( Fig. 13.31 
). For every collected image a Gaussian curve is fitted and signal threshold T„ is 
calculated as multiplicity of sigma value ( typically T„ = bas or Ga^ ). 




Figure 3.2: Sky image before and after applying the laplace filter 
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Figure 3.3: Distribution of laplace 12 values on a single image 
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3.2 On-line flash recognition algorithms 

The aim of this type of algorithms is to find optical fiashes occurring in single im- 
age time scale ( 10 sec ). The signature of such events is the following. Interesting 
event is an object which appears in a new image of the sky and was not present in 
the previous image of the same field which was taken a moment before. However, 
this simple idea is not so simple in practical realization. Most of the events found 
by such simple comparison of two images are due to background. The crucial 
task of the efficient algorithm is to reject most of the background without too 
much loss of the signal. It is realized by a multilevel triggering system based on 
ideas used in particle physics. Every image consists of 4 ■ 10^ pixels suspected of 
being potential interesting event. Image should be analysed while next image is 
being collected which takes ~ 12s in the current configuration. This means that 
the algorithm must be fast. First trigger levels are simple and fast, they reject 
big amount of event candidates with simple criteria. Higher trigger levels have 
more time and can use more sophisticated criteria to reject background events. 

3.2.1 First Level Trigger 

This level of algorithm must handle the highest data rate, so it must be very fast 
and simple. It should preserve most of the signal and reject big fraction of non- 
interesting pixels. At this stage fiash-like events in single camera are identified 
and saved to log files and optionally to the database. The following list of cuts 
are applied to every pixel in the image : 

• Tn - this cut selects stars on new image by requiring signal in the analysed 
pixel. The condition for signal presence is : 

N{x,y)>T^ (3.2) 

where N(x,y) is ADU value in pixel (x,y) of the new image and the threshold 
Tn is specified by DAQ configuration parameters in multiplicities of ctb ( 
see Tab. 13.11 and Fig. 13.31 ). The goal of this cut is selection of all stars in 
new image. 
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• T„ - this cut rejects constant stars. It requires that there is no signal on 
the previous frame. "Previous frame" in this case means not just one single 
image, but average of several previous images. The condition imposed on 
value of pixel in the "previous image" is the following : 



P{x,y)<T, (3.3) 

where P(x,y) is the value in pixel (x,y) on the average of N aver previous im- 
ages. Pixels remaining after this cut should be new objects which appeared 
on new image and were not present on previous images. 

• MinLaplace - rejects pixels which have value on previous image lower 
then minimal accepted value ( TMinLap )• This cut allows to reject edges 
of bright stars where values of pixels after laplace filter often become 
negative, but can also vary to values exceeding Tn. 

• IfMoreAfterTv - rejects the whole image if number of pixels accepted after 
T„ cut exceeds certain limit NMaxTv This cut allows to reject images with 
big number of events which are due to system error, Moon light or clouds. 
The image is bad, all events are certainly rubbish so they are rejected and 
no further analysis of this image is performed. 

• LocalMax - requires that pixel value is a local maximum. This cut allows 
to choose only one pixel of star like object for further analysis. 

• SkipOverlaps - checks number of accepted pixels in certain radius Roveriap 
from current pixel and leaves only one event and skips the others. This cut 
narrows the number of pixels to be analysed which are related to the same 
object to a single one. 

• Shape - object shape indicator S is calculated. It is defined as : 

S = (3.4) 

^circle 

where Sduster is area of cluster and S circle is the area of the smallest circle 
circumscribed on this cluster. Cluster is defined as group of pixels around 



3.2 On-line flash recognition algorithms 



current pixel with values satisfying N(x,y) > Tduster- Shape is required 
not to be elongated by imposing : 

S> > Tghape (3-5) 



The idea of shape calculation is shown in Figure I3.4[ The distribution of 
shape value for stars in single image is shown in Figure I3.4[ 




Figure 3.4: Idea of shape indicator calculation (left) and its distribution for events from a single 
night and camera (right) 



• BlackPixels - this cut rejects pixels which have much smaller signal then 
neighboring pixels causing laplace filter to be high due to underestimation 
of the background level. The following requirement is imposed on every 
pixel : 

^ p d. J-black (-J-DJ 

where P_ is value of pixel entering the laplace function with minus sign. 
Black pixels on reduced image can be due to CCD defects or temperature 
fiuctuations, but are rather very seldom ( Tab. 13.21 ). 
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• HotPixels - due to CCD chip defects some pixels can give much higher 
signal then normal good pixels. Such effects should generally be subtracted 
by the dark image subtraction. However, sometimes it is not enough, be- 
cause new hot pixels can appear temporary during a night and become 
quiet again later. The main reason for this are excitations from cosmic ray 
hits. Two ways of rejecting such events have been implemented. The first 
one is calculation of average value in pixel on previous images, the imposed 
criteria is : 

^ < J^hot 

aver 

where Pi{x, y) is ADU value in pixel in image i before current one. In the 
case of tracking mount this cut is neutral due to cut which is stronger. 
Second anti-hotpixel cut is rejection of pixels by the list of known hot- 
pixels. This list is updated regularly when new defects are found. This is 
done "manually" by running report which shows events described as hot 
pixel. In case certain pixel is regularly giving false alerts it can be added to 
list of known hot pixels which is stored in the database ( Fig. 13.261 ). 

• IfMore - checks nearby events in distance of Rifmore pixels, in case number 
of events exceeds limit of Nifmore all nearby events are rejected. This cut 
allows to reject events caused by planes or satellites. 

Parameters for algorithms are passed as described in the Section [2. 2. 2. 61 The 
parameters used in First Level Trigger (FLT) are listed in Table \3A\ 

The output from FLT is basically a list of events from single camera. These 
events are saved to a log file allevents_N.log ( N stands for index of camera 
). Optionally they can be saved to database to provide easy access for further 
analysis. Table [3^2] shows background rejection efficiency of subsequent FLT cuts. 

3.2.2 Second Level Trigger 

The action at this level depends on the type of the system setup. Generally three 
configurations are possible : 
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Cut 


Parameter Name 


Value for 
confirmation 
on next 


Value for 
coincidence 


Notes 


LaplaceType 


LaplaceType 


12 


12 


For Carl Zeiss f— 50 laplace— 4 


T„ 


T„ 


6 


5 


For Carl Zeiss f=50 T„=5 


T„ 


T„ 


2 
7 


2 
7 


For Carl Zeiss f=50 T„=2.5 
Number of averaged previous images 


MinLaplace 












IfMoreAfterTv 




3000 


3000 




SkipOverlaps 
SkipOverlaps 


SkipOverlaps 

^overlap 


1 

4 


1 
4 


enable/disable 
radius in which overlaps are skipped 


Shape 




0.2 


0.2 




BlackPixels 




0.5 


0.5 




HotPixels 




3.6 


3.6 


Threshold in anti-hotpixel cut 


IfMore 


RifMorc 


20 
150 


20 
150 





Table 3.1: FLT parameters summary, real names of parameters used in configuration files can 
be found in Table \BA\ in Appendix lB.il 



Cut 


% of all events 


% of events from previous level 


Number of events 


All 






3.212 ■ 10" 


Tn 


2.06 - 10"^ 


2.06% 


66434214 


Tv 


2 • 10"'' 


0.1% 


68345 


MinTv 


2 • 10"^ 


96.99% 


66293 


Overlap 


5 . 10-" 


25.79% 


17100 


Black 


5 . 10-" 


100% 


17100 


Hot 


5 • 10-" 


100% 


17100 


IfMore 


5 . 10-" 


99.85% 


17075 


Coinc 


2.5 • IQ-" 


46.28% 


8099 


Satellites Catalog 


2.49 • 10-" 


98.96% 


8015 


Star Catalog 


2.32 ■ 10-" 


93.11% 


7463 


Shape 


2.25 • 10-" 


97.10% 


7247 


Tracks 


1.55 • 10-" 


0.06% 


5 


Accepted 


1.55 ■ 10-'^ 


0.06% 


5 



Table 3.2: Number of events remaining after subsequent cuts of coincidence algorithm for night 
2006-05-27/28 
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• two cameras on a single mount working in coincidence. In this configuration 
events found by the first camera are verified in the corresponding image from 
the second camera. Only events present in images from both cameras are 
accepted. This configuration is realized by the prototype system in LCO. 

• single camera, coincidence is replaced by confirmation of signal on next 
image. This version of algorithm was also realized in LCO when one of the 
cameras was not working due to technical problems. This can be used as 
cross-check algorithm for two cameras working in coincidence. 

• two cameras in separate locations working in coincidence. This will be 
realized in the full version of the system. Cameras will be paired, both 
cameras in the pair will observe the same field in the sky. Spatial and time 
coincidence of the flash in both cameras will be required. 

In any case coincidence requirement is one of the most important cuts. The 
main goal is rejection of cosmic rays hitting the CCD chip and imitating as- 
trophysical flashes (Fig. 13. 5p . In many cases cosmic rays have Point Spread 
Function (PSF) completely different then PSF of stars and they could be re- 
jected by a shape recognition procedure. However, in some cases they are very 
similar to PSF of the stars. Even if this is a very small fraction of all cosmic 
ray events this would cause all flashes found by the algorithm to be uncertain. 
A way of definite rejection of all cosmic rays events is required for credible flash 
recognition algorithm. Probability that different cosmic ray particles will hit two 
chips in the same time and in the same positions ( with respect to stars ) is neg- 
ligible. Coincidence is also very effective way of rejecting background events due 
to sky background fluctuations, edges of bright stars and clouds. In the proto- 
type version cameras take images parallely so the only parameter is the angular 
distance of events in both cameras, currently used default value is Rcoinc = 150 
arcsec ( 250 arcsec was used for Carl Zeiss f=50mm lenses ). It was determined 
from distribution of angular distances of corresponding stars in both cameras ( 
Fig. ESI). 

In the case of coincidence between cameras in separated sites, the significance 
of coincidence is even bigger. In this configuration it is possible to reject close 
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Figure 3.5: Examples of events caused by cosmic ray hitting the CCD chip, with PSF easy to 
distinguish from stars (upper image) and very similar to PSF of stars (lower image) 
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Histo_coincidence_radius.txt 



Entries 15900 
Mean 588.1 
RMS 1241 




3000 4000 5000 
Distance of events [arcsec] 



Figure 3.6: Distribution of angular distances between events from corresponding images col- 
lected by cameras k2a and k2b during night 2006-05-28/29. Events with the distance < 250 
arcsec are accepted. 
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Earth flashing objects using the parallax ( Fig. 13.71 ). Artiflcial satellites orbiting 
the Earth may rotate and sometimes reflex Sun light causing flash-like events. The 
best method to distinct such kind of flashes is to use parallax. In the prototype 
version of the experiment two cameras are installed on single mount. However, 
this method was .e*d by coincidence wi.h .he RDOT experiment located 
on La Silla at the distance of ~ 30 km. 



Viewpoint A 




□ 




Distant bac^^groui'iG 



V<ewpolnl A 



□ 



Viewpoint B 



s 



Figure 3.7: A simplified example of parallax ( image taken from 



Image collected by the prototype containing an optical flash was compared 
with image of same area of the sky taken by RDOT telescope at the same time. It 
can be clearly seen in Figure [3^81 that optical flash is visible in different positions 
with respect to the stars. Requirement of spatial coincidence would reject such 
event. It is probably caused by a satellite in distance of < 25000 km from Earth. 
This method has been tested for a few nights only. During normal operation it 
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4:32:34-4:32:44 4:32:46 -4:32:56 4:32:58-4:33:08 




RDOT 




Figure 3.8: Stereo observations of near Earth satellite by experiments PI and RDOT 
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is not possible for the prototype to use parallax to reject flashing satellites. In 
order to reject most of such events a database of known satellites is used. It is 
retrieved every night from the Internet and contains ~ 10000 orbital elements. 
For every image, positions of all satellites in the database are calculated and every 
flash candidate is verifled. In case it is closer then Rsat = 0.5° from any of the 
satellites it is rejected. The rejection radius was determined from distribution 
of angular distances from flashes to closest satellite from the database which is 
clearly peaked around zero ( see Fig. 13.91) . 

The red dots on this plot represent distribution of distances to the closest satellite 
from the catalog for randomly distributed flashes. A clear peak at Rsat < 0.5° is 
visible, it corresponds to real satellites. 

The orbital elements databases are not complete, there are many satellites 
which are not included ( e.g. spy satellites ). In order to reject such kind of 
objects event candidates from many consecutive images are examined against 
track conditions. In case it is possible to flt track to set of events from different 
images and velocity of object is constant all events on the track are rejected. This 
rejects big fraction of flashing satellites and planes ( see Fig. 13.101 ). however it 
is possible that rarely flashing ( rotating ) satellites survive this cut. 

At this level of the trigger each event candidate is checked against the catalog 



of constant stars. TYCHO-2 star catalog [57|| is used for this purpose. The event 
candidate is rejected in case there is a star brighter then Magmax in radius Rstar 
(see Tab. 13.31) . Stars can imitate flashes mainly due to clouds. When cloud moves 
and uncovers a star the FLT identifles such an event as flash. All events accepted 
by coincidence are saved to flies verifiedevents_W.log and optionally to the 
database. Events accepted by the SLT are saved to finalevents_N.log and to 
the database. Parameters used in the SLT are listed in Table [3731 Block diagram 
of on-line flash recognition algorithm is shown in Figure [3.12[ Rejection efficiency 
of subsequent FLT and SLT cuts are show in Figure 13.111 

3.2.3 Third Level Trigger 

The first two levels of the trigger retain very small number of events, on average 
it is not more then 10 per night. It depends strongly on weather conditions and 



3.2 On-line flash recognition algorithms 



10' 



(/) 

4^ 

c 
> 



0) 5 

3 



10 



=^Rsat = 1800" 



Histo sat 


_radius.txt 


Entries 


3051 


Mean 


1612 


RMS 


2804 




2000 4000 6000 8000 10000 12000 14000 16000 18000 
Distance from event to closest satellite [arcsec] 



Distance 



V) 



0) 

> 

0) 



0) 
£1 

E 



10== 



o closest satellite : night 20070526 and MC 



Rsat = 1800" 



Night 20070526 

• MC 



Distance to closest satellite 



Entries 9660 
Mean 8346 
RMS 4750 




)0 4000 6000 8000 10000 12000 14000 16000 18000 

Distance from event to ciosest sateiiite [arcsec] 



Figure 3.9: Distribution of distance from flash event candidate to the closest satellite from the 
catalog. For events found by coincidence algorithm during night 2004.10.28/29 (upper plot) 
and for single camera events from night 2007.05.26/27 (lower plot). 
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Cut 


Parameter Name 


Current Value 


Notes 


Coincidence 




150" 


It was 250" for objectives f— 50mm 


Confirmation on next 




1 


in case of 2 cameras working it is 


Satellite Catalog 


Rsat 


1800" 


angular distance from satellite to reject event 


Star Catalog 


Rstar 
Magmax 


120" 
13 


angular distance from catalog star to reject event 
minimum brightness of used catalog stars 


Track 


Nt^ack 


200 


number of subsequent images used for track fit 




2 

Xadd 


700 


Maximum allowed distance ( in pixels squared ) from 
existing track to match event to this track 






100 


Maximum value of to initialize new track 



Table 3.3: SLT parameters summary, real names of parameters used in configuration files can 
be found in Table [R2l in Appendix [Ell 
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Background rejeclion by subsequent cuts 



S 10- 



k2a 



Confirmation on next image 




S^S^ CutName 



Background rejection by subsequent cuts 




Figure 3.11: Background rejection efficiency of algorithm requiring confirmation of flash on 
next image (left) and coincidence of two cameras ( right ) 



in case of cloudy night this number can reach hundreds, but in this case fast 
inspection can reject most of them. However, in the full system the number of 
events will be 16 time larger reaching 100-200 per night and this will be much 
more difficult to inspect. For this reason the third level of the trigger has been 
implemented. It checks final events accepted by previous levels which ensures 
that only small number of events will be examined. Thus it is possible to im- 
plement much more sophisticated and time consuming algorithms to check every 
event. Current implementation of the TLT consists of the following cuts : 



• Comparison of event on both cameras and require signal to be similar on 
both cameras, by imposing condition : Lmin/Lmax < Ldiff 

• Checks sphericity again with optionally more strict criteria Shape < Tjf^'^p^ 

• Simple Hough transform - uses small image part surrounding event. It 
finds pixels with signal above certain level Though and creates distribution 
of coordinate ( = atan{{y — yO)/{x — yO)) ). In case this distribution 

^ Hough transform is a technique of image transform from (x,y) to cylindrical (r,(/)) coordi- 
nates in order to find particular shapes in an image 
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Calculate filtered image 
( called since now L image ) 



OPTIONALLY - ONLY IF CONFIRMATION IN THE NEXT IMAGE IS REQUESTED 
Check all events found on previous image, verify if tfiere is signal 
on next image 



Camera 1 analysis : 
Apply subsequent cuts described in the text of the section 
Basically these are : 

1/ Tn cut ( stars selection ) 
2/ Tv cut ( constant stars rejection ) 
3/ Rejection of saturated pixels 
4/ MinLaplaceOnPrev cut ( rejection of stars edges ) 
5/ IfMore cut : rejection of all nearby event if to many 
6/ Rejection of whole image if too many events at this level 
71 Local Maximum cut 
8/ Rejection of overlaping events 
9/ Black pixels cut 
10/ hot pixels cut 
1 1/ check tracks on single camera events ( if required ) 

Add resulting events to list of events from single camera. 
Dump list of events from single camera to log file ( optionally also to DB ) 
Same steps as above are done for other camera 



Check concidence of events from events lists from 

k2a and k2b camera. 
Conciding events are mostly of astrophysical origin, 
following subsequent checks are done : 

1/ rejection of satellites from orbital elements catalog 

2/ rejection of constant stars according to own catalog 

3/ track check - in case events line on streight line they 

are all rejected ( by default 200 back images are considered ) 

All events accepted by the concidence are dumped to separate log file 
verifiedevents_N.log ( optionally to DB ) 
Events accepeted after step 3/ are saved to finalevents_N.log and 
also to database 



Figure 3.12: Block diagram of on-line flash recognition algorithm 
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has significant peak this means it is probably due to straight line from a 
plane or a satellite ( Fig. 13.131 ) 




Figure 3.13: Original event image (left image) and distribution of </> angle coordinate for back- 
ground event (right image) 



Event will be considered as straight line if the maximum of distribution of 
angle (p satisfies the following condition : 

Nmax{(i>) > MEANy + Though_ distr 

*RMSy 

AND (3.8) 

Nmaxi<P) > Though _height * MEANy 

• Track check : checks event against fitted tracks if the event was not correctly 
merged to existing track by the on-line algorithm 

• Algorithm on parts : algorithm is re-run on small parts around the event, 
with less strict threshold T^^'^ = A - as- The event is rejected if tracks are 
found and it belongs to one of these tracks. 

• Cloud check : checks number of stars in the full image and rejects event if 

Nstars < 8000. 
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• Frame line : in case line can be fitted to events from a single frame rejected 
by Hough transform, all events from the same frame and not yet rejected, 
are matched to this line. In case event matches this line it is rejected 

• All line check : checks if straight line can be fitted to events from final list. 
It rejects final events matching this line. 



Cut 


Parameter Name 


Current Value 


Notes 


Hough Transform 
Hough Transform 
Hough Transform 


Though 
Though distr 
Though height 


1.5 
4.5 

2.0 


Threshold for choosing pixels 
Threshold for peak in distribution 
(in a ) 

Threshold for minimum peak height 
( in multiplicity of mean value ) 


clouds cut 
clouds cut 


Ntsta^s 
^clouds 


40000 
0.2 


typical number of stars on whole image 
reject if when number of stars in the 
image < Rdouds ' ^tstars 


Event Comparison 


Ldiff 


0.25 


requires similar signal on both cameras 


Algorithm on parts 


j,TLT 


4.00 


more loose then normal 



Table 3.4: TLT parameters summary, real names of parameters used in configuration files can 
be found in Table [b31 in Appendix lB.il 

Events rejected by this level of algorithm are not excluded from final list of 
alerts claimed by the system. They are only fiagged, this fiag can be useful 
indication for a person inspecting all night events. Results of TLT are saved to 
log file and database. Parameters used in TLT are listed in Table 13. 4[ 

3.2.4 Optimization of algorithm parameters 

Optimization of algorithm parameters was a very important step of algorithm de- 
velopment. Algorithm parameters can be changed by settings in the ccd. cf g file 
as described in section [2. 2. 2. 61 Tables [3TT] and [3731 list most important parameters 
of algorithms on first and second levels of the trigger. 

Some parameters were optimized by specific studies and the others were opti- 
mized by running algorithms on sky data with simulated optical fiashes. Testing 
of algorithms was performed on regular sky images. Exactly the same software 
was used, but instead of reading images from the camera like during regular night 
observations, the images were read from the fits files stored on a disk. Images 
were analysed and found events were considered as background events. Optical 
flashes were simulated in such a way that samples of stars of given brightness 
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were extracted from images and pasted in an image in random positions. Single 
test of given parameters set was performed on all images from a single night, 
program was analyzing subsequent images and one generated flash was added in 
every image. After all images were analysed the number of background events 
Nbkg was calculated, as those which were found by the algorithm, but were not 
generated. Generated events were checked on the list of identified events and 
number Ngenident of those generated and identified was determined. Efficiency of 
identifying optical fiashes of given magnitude was determined as : 

e{mag) = (3.9) 

Every set of tested parameters was plotted as a single point in the plot of e vs 
Nbkg- Different points on this plot show values determined for different settings of 
the algorithm. For every star magnitudo separate plot was created. Figures 13. 141 
and 13.151 show results of efficiency and background rejection tests for algorithm 
requiring confirmation of fiash in the next image performed on ~500 images from 
night 2007.04.25/26. These plots were created for simulated fiashes of 9™ and 10*" 
respectively. The best values of efficiency are also shown in Table 13.61 According 
to these results optimal parameter values were chosen ( see Tables [3T] and [3731 ) . 

The efficiency and background tests were also performed for the coincidence 
algorithm. The Figures 13.161 show best points of T„ and thresholds. 

The efficiency losses due to subsequent cuts of on-line algorithm was tested. 
It was done by counting how many of generated samples were rejected by on-line 
algorithm cuts. Figure 13.171 shows efficiency losses due to subsequent cuts for 
data collected during single night. 

The efficiency of on-line algorithm cuts was determined for several different 
nights ( Fig. 13.181 ). The mean efficiency is ~ 70%. The testing procedure 
which pasts samples of stars into image does not take clouds into account. In 
fact this procedure allows to estimate efficiency of all cuts after Tn cut. This is 
because sample is pasted in an image on top of clouds, so there is no possibility 
to have large loss of efficiency due to clouds in such kind of testing procedure. 
The average efficiency of Tn cut was estimated as e^n ~0.49 with usage of the 
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Background vs Efficiency for mag=9 and laplace=4 
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Figure 3.14: Efficiency of 9™ flash recognition and background rejection by an algorithm requir- 
ing confirmation of event on next image. Test was performed on data from night 2007-04-25/26 
for laplace=4 (left plot) and laplace=12 (right plot) 
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Figure 3.15: Efficiency of 10"' flash recognition and background rejection by an algorithm 
requiring conflrmation of event on next image. Test was performed on data from night 2007- 
04-25/26 for laplace=4 (left plot) and laplace=12 (right plot) 
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Table 3.5: Best values of efficiency of confirmation on next image algorithm obtained for simu- 
lated fiashes of brightness 9™, tested on 500 images from night 2007-04-25/26. 
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Figure 3.16: Results of efficiency of 9™ fiash recognition and background rejection of coincidence 
algorithm. Tests were performed on data from night 2006-05-26/27 for laplace=4 (left plot) 
and laplace=12 (right plot) 
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Table 3.6: Best values of efficiency of coincidence algorithm obtained for simulated flashes of 
brightness 9™, tested on 1952 images from night 2006-05-26/27. 




Figure 3.17: Efficiency losses due to subsequent cuts of on-line algorithm : confirmation on 
next image (left plot), coincidence (right plot) 
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TYCHO-2 star catalog and cataloging procedure ( see Sec. I3.3.1.4I ). This gives 
average efficiency of flash identiflcation algorithm eaigo ~0.35. 
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Figure 3.18: Acceptance of on-line algorithm cuts in function of average number of stars on all 
images collected during a single night. Each point represents efHciency during a single night. 

3.2.5 Sources of background 

Final list of events from one night of the prototype work did not exceed 100 
events , but typically remained on the level of 10 events per night. These events 
were mainly due to background events. The main sources of the background were 
flashing satellites, planes and meteors. There was also background due to clouds, 
in this case usually number of events on cloudy images was big so it was easy 
to simply reject whole image. Summary of background events statistics is given 
in Table 13. 71 This table is divided into periods and types of algorithms in the 
cases where more then one algorithm was running. Example of background event 
images are given in Figures 13.191 13.201 13.211 and I3.22[ 
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Table 3.7: Statistics of classification of events from on-line algorithm in period 2006.06 - 2007.06 
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Figure 3.19: Rare example of coincidence of two cosmic ray hits 
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Figure 3.20: Plane-like background event 
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Figure 3.21: Meteor trace blown by the wind 
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Figure 3.22: Flotilla of artificial satellites 
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3.2.6 Final verification of events 

The final list of accepted events is very small. However, the prototype does not 
have a possibility to definitely reject all background events. The most difficult 
part of the background are fiashing satellites. They are mostly rejected by cat- 
alog and track cuts described in the previous sections, but some objects are not 
cataloged and fiash too rarely to be rejected by these criteria. Final events can 
be evaluated by several checks. In the case when object suddenly appears and 
remains visible in the next several images in the same position it is very probable 
that it is not a satellite. Assuming the object is Earth's satellite the following 
formula can be derived : 



where a is the angular distance of the object in consecutive 2 images and (5t 
is the time separation of images. They can be substituted in arcmin and seconds 
respectively if formula on the right is used. In the case of the prototype a ~ 0.6' 
which corresponds to a single pixel and bt ~ 12s which corresponds to time 



distance of the object visible on 2 consecutive images in the same position derived 
from these values is D ^ 123 000 km. For comparison, the geostationary orbit is 
Rgeostat ~42160 km ( from the Earth center ). 

The distribution of the distance from the Earth to satellites in the catalog is 
shown in Figure 13^231 Peak from geostationary satellites is clearly visible. There 
are not many satellites more distant then 50000 km, which supports "double 
image" events. However, it is possible that these flashes are caused by spacecrafts 
on the long missions which are very far objects and can also reflect sun light 
towards the Earth. The probability of such events is very small. The above 
check can not be applied to events visible only in a single image. For this class 
of events another check was implemented. Flashing satellites can only reflect sun 
light when they are outside the Earth shadow cone and not on the illuminated 




(3.10) 



separation of 2 subsequent images ( 



exposure 



+ Tdead= lOs + 2s ). The minimal 



side of the Earth (Fig. KM) . 
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Figure 3.23: Distribution of distances of artificial satellites from the center of the Earth. Peak 
at w 42000 km is due to geostationary satellites. 
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Figure 3.24: Positions where satellites can reflect sun light 
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Knowing the position and time of the flash it is possible to calculate the 
satellite's minimal distance from the Earth to be outside of the shadow cone 
which is required for the satellite to cause a flash-like event. The Earth shadow 
cone size is Hcone ~ 1,37 mln km ( Fig. 13.241 ), which is more then Moon's 
orbit size ( Rmoon ~ 400000 km). In case any of the flash candidates would have 
Dcone > Rmoon it would bc most probably an event of astrophysical origin. 

3.3 Off-line data analysis 

Off-line data analysis acts on data reduced and cataloged to the database. The 
reduction chain consists of several steps which will be described in detail in the 
next subsection. After this chain, star brightness measurements are stored in the 
database which is optimized for fast access. The structure of the database will 
be described in subsection 13.3.1.21 In the last subsection algorithms for detecting 
brightness increases and new object appearance will be described. 

3.3.1 Reduction pipeline 

The aim of the reduction procedure is to reduce raw data stored as images in 
fits files into essential data describing stars coordinates and brightness. This 
allows to reduce the amount of data by factor of ~ 10 in the case of single images 
and ~ 100 in the case of 20 averaged images. 

3.3.1.1 Image reduction 

Every image collected during a night is processed in the same way. Off-line data 
analysis described in this thesis was performed on data obtained by averaging 20 
subsequent images. There are also other reduction pipelines for reducing single 
image and scan images ( averaging 3 scan images ) , but almost all of the steps are 
the same. The main difference is that in pipelines acting on averaged images there 
is an additional step calculating average of specified number of images. Image 
reduction consists of the following steps : 

• image averaging - it is present in reduction pipelines acting on averaged 
images. In the case of aver20 pipeline 20 subsequent images are averaged 
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and in the case of pipeline scanS 3 subsequent images are averaged. Image 
coordinates are controlled and in case they change, average chain is stopped 
not to allow for averaging images from different positions. In the case of 
single image reduction the image averaging step is skipped. 

• Dark frame subtraction - the reason for dark frame subtraction was already 
described in Section 13. 1[ As described in Section 12.2.2.31 in order to reduce 
fluctuations the dark image is calculated as a median of several dark images. 
This step allows to subtract signal offset produced by dark current and 
electronics. It also reduces the effect of hot pixels. 

• Division by flat image - this step allows to correct for non-uniformity of 
the optics and differences between pixels ampliflcations. Standard way of 
flnding this correction is taking images of uniformly illuminated field. It 
is usually the sky just after dusk or just before dawn, when the sky is 
bright and stars are not visible. An alternative way is to use uniformly 
illuminated screen. In case of wide field observations it is very difficult 
to obtain proper fiat image. It is due to difficulty of obtaining uniformly 
illuminated field of size of FOV > 20°. The evening sky just after sunset 
is uniformly illuminated in scale of arc minutes, but in scale of degrees non 
uniformities due to sky gradient are significant. Due to this problem fiat 
image is obtained by taking images of evening sky with the mount tracking 
switched off. After taking many images and calculating median image stars 
are eliminated, finally the image is normalized to one. This procedure 
requires collection of many (>200) images so it is performed rarely and for 
most of the time the same fiat image is used in analysis. 

After the above operations the image is ready for photometry. The photome- 
try is a procedure which finds stars in the image and determines their chip coordi- 
nates (x,y) and brightness. In the "Pi of the Sky" data analysis two photometry 
procedures are used depending on the type of reduction pipeline : 



ASAS photometry - aperture photometry adopted from ASAS experiment 
42|. It is rather slow so cannot be used for reduction of all single images 



3.3 Off-line data analysis 



from a night. It is used for photometry of 20 averaged images ( ^ 20 ■ 12 = 
240 sec timescale ) and in reduction of scan images ( 3 images averaged ). 

• Fast photometry - it is fast, aperture photometry algorithm. Simple aper- 
ture is used to calculate star brightness. This photometry is used on-line 
by DAQ to perform astrometry every 300 sec and in reduction of all night 
images ( ASAS photometry is too slow for this purpose ) 
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Figure 3.25: Aperture used in fast photometry algorithm 



Aperture used for brightness calculation is shown in Figure 13.251 Final 
brightness of star is determined as : 

N+ 

I = Y,P+-N+-B,ky (3.11) 

i 

where Bg^y stands for average value of sky background near analysed star. 
This value is obtained as median value of pixels in gray ring around the star 
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( Fig. 13.251 ). P+ denotes signal pixels, shown as dark gray pixels inside 
the star, they form 3x3 square around the maximum brightness pixel with 
3 most bright pixels contiguous to the square sides. This procedure is not 
good for dense fields where sky background can be calculated incorrectly 
due to stars entering the "background ring" and also ^f^^ P+ is affected by 
overlapping stars. Instrumental magnitude is calculated from the formula : 

= -2,5log{I) (3.12) 

Star coordinates (x,y) are determined as centroid of cluster of pixels ac- 
cording to the formula : 

Y — '^cluster •^i " ^ ^^ _ '^cluster ' ^ (o i q\ 

^star -rr ) ^ star -rr (^O.iOj 

/—icluster * /-^cluster * 

Cluster of pixels is determined as pixels around the star which satisfy P(x,y) 

^ Tcluster — 3.5 ■ (7. 

Both photometry procedures write resulting list of stars with (x,y) coordi- 
nates and magnitudes to output mag files. The format of this files is similar to 
fits format. They consist of header which is taken from fits header with some 
additional fields added, after the header section, list of stars in binary format is 
written. The mag files are input files for astrometry procedure. 
This procedure finds transformation T:(x,y) — > (A, 5), the transformation T is 
described by the following formula : 



ij<0 i,j<0 

Where O is the order of the transformation, in current configuration 0=4 
and due to this fact coefficients Pu, P23, -P24, -P32, -Pss, -f34, -P41, -f42, -Ris, -P44 = 
and also corresponding Q coefficients are zero. It allows to calculate equatorial 
coordinates for any chip coordinate (x,y). Astrometry requires input informa- 
tion about image center position, pixscale0 and rotation angle of the image with 

^pixscale is an angular size of the CCD pixel 
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respect to the celestial coordinates, these settings are read from header of mag 
file. The astrometry procedure was adopted from the ASAS experiment, it is an 
iteration procedure where stars in mag file are matched against catalog stars in 
given position in the sky. Star catalog currently used in the procedure is based on 
TYCHO catalog, however any star catalog can be used instead. The procedure 
consists of the following main steps : 

• loading of mag file 

• read stars from the reference star catalog 

• estimation of shift from the expected position (A, 6)mount and real position 
(A, 6) using the correlation function between image stars and stars in the 
catalog 

After the above initialization steps the iterational procedure begins, every it- 
eration consists of the following main steps : 

• recalculation of reference and image stars coordinates to standard coordi- 
nates ( with respect to image center ) 

• matching of image stars from mag file against reference stars 

• determination of transformation parameters by using the method of singular 
value decomposition (SVD). 

• check the convergence condition requiring astrometry error 6a < SaMAx 

• recalculation of image center coordinates (A, S)center 

The iteration steps are repeated until the convergence conditions are satisfied. 
In the case astrometry procedure converges, for all stars in the mag file coordinates 
(A, 6) are calculated from the formula [3.141 The results are saved to ast file which 
consists of same information as mag file with additional fields for (A, 6). All night 
images are processed in the same way and every sky image (fits file ) has a 
corresponding ast file. 
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3.3.1.2 Star Catalog 



The star catalog is developed as relational PostgreSQL database [49||. The database 
structure is shown in Figure 13^261 It consists of tables described earlier in Section 
I2.2.2.5I with additional tables : 

• Star - this table contains all objects observed by given camera. Same 
physical star can be observed by many cameras so same physical star has 
N>1 records in the table Star, where N stands for number of cameras by 
which this star was observed. 

• Measurements - this table stores information on every observation of the 
star. It is linked to table Star by reference field star, it is also linked by 
field id_f rm to Frame on which the star was observed. 

• SuperStar - it is a table containing real physical stars. In case star is 
observed by different cameras it has multiple records in table Star, but 
only one record in the table SuperStar. Every record in the table Star is 
linked to corresponding SuperStar record by field sstar_id. The relation 
between SuperStar and Star table is one to many. 

• ObsFieldStat - statistical table containing information on number of im- 
ages collected for a specific field 

• Field _Def - definitions of fields observed by the system 

Star catalog database can be huge, after year of data collection it can reach 
50-200 GB ( aver20 database ), so in order to be efficiently used it must be opti- 
mized. An important element of the database structure are indexes. They allow 
searching indexed fields by fast binary search algorithm. The most important 
database queries were optimized by creating indexes on fields used in conditional 
statements. Another optimization performed on the database is placing Mea- 
surements records for a given star in the same physical location on the disk. 
This is very important for fast reading of star light curves. This optimization is 
executed by PostgreSQL command CLUSTER which must be called from time 
to time after large amount of new data is added to catalog. Also table Star is 
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Figure 3.26: Structure of star catalog database 
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optimized by CLUSTER command according to the celestial coordinates in order 
to optimize reading of stars from database during cataloging. The most impor- 
tant indexes are listed in Table I3.8[ There are also database optimizations on 
PostgreSQL server configuration level which set parameter value proper for huge 
database. 



Index Name 


Table 


Indexed Fields 


Clustered 


stars_id_index 


STARS 


ID 


no 


stars_ra_dec_index 


STARS 


ra,dec 


yes 


stars_dec_index 


STARS 


dec 


no 


superstar _gcvs_id_index 


SUPERSTAR 


gcvs_id 


no 


measurements_star_index 


MEASUREMENTS 


star 


yes 


measurements id frm index 


MEASUREMENTS 


id frm 


no 



Table 3.8: Indexes most important for optimizing star catalog 



3.3.1.3 Cataloging procedure 

Reduced data is a set of ast files, these files have to be loaded to the database 
structure described in the previous section. This task is called cataloging and is 
performed by piaddast2 program. Except of loading data to the database this 
program normalizes star magnitudes according to V filter magnitudes in catalog 
of reference stars. The block diagram of the piaddast2 program is shown in 
Figure 13.271 Generally, cataloging procedure reads stars already observed before 
from the database and matches new observations to these stars. Subsequent ast 
files are organized in the memory until observation field changes which triggers 
dump of data from memory to the database and selection of stars for new position. 
Every ast file is processed in the following way : 

• Read next ast file, determine range of celestial coordinates in ast file 

• Save image header information to database tables FRAME and FRAME_DET. 

• Check if all stars in ast file have coordinates in the range (A^^*^^', 5^^^) — 
(-^maa;; ^max)- ^asc there are stars from outside this range program dumps 
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J List of ast files 



Dump stars and measorements from memory 
to sql files andloadtliese files to DB 




It statistics of 



J next ast file 



Optimize database ( create indexes and clusters ) 



Save image information from header to database 
table Frame andFrameDet 



Dump stars and measurements from memory 
to sql files and load these files to DB 
Find range of coordinates in new ast file: 
ast_min_ra,ast_min_dec)-(ast_maxja,ast_max_det 
and read stars from this range from the database 




Using reference catalog find map of magnitude correction 
which must be added to instrumental magnitude to 
obtain absolute magnitude, calculate normalized 
magnitude for all stars in ast file 



Add stars (from ast file) which satisfy the quality cuts 
( described in the text ) to list of stars and measurements 
stored in memory 



Figure 3.27: Block diagram of the cataloging program 
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stars and measurements stored in memory to sql files and loads sql files to 
the database, then selects stars from database with coordinates matching 
range of coordinates in new ast file ( as determined in first step ) 

• Check if the image represented by the ast file is good enough to be cata- 
loged, the following criteria are checked : 

- number of images used for averaging ( in the case of cataloging aver- 
aged images ) for 20 averaged images the lower limit is 10 images and 
for scanS pipeline lower limit is 3. 

- check if N^Jl!^.^^ > N^^JJ^{= 5000) , in case number of stars is lower it 
means that it is probably cloudy image ( Fig. 13.281 ) . 

- check if number of stars is not too high : N^^^^ < N^J:^{= 70000) ( 
Fig. 13.281 )■ which indicates bad image. 

- check if average astrometry error is not too large : Aerr < ^CTr^(= 0.3) 
( Fig. [32i) 

In case all criteria are satisfied ast file is accepted and stars are cataloged, 
otherwise it is skipped. 

• Each star in ast file is examined against certain quality cuts : 

1. Star altitude is required to by h>/imm=15°, in order to reject mea- 
surements close to horizon which are of very poor quality 

• Star magnitudes are normalized by comparing with the catalog of reference 
stars. Matching allows to create correction image ( Fig. 13.301 ) which can be 
used to normalize magnitudes of all stars in the image. The normalization 
is performed in the following way : 

- catalog of reference stars is read to memory 
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Image star number distribution 



HistoJmage.stars.txt 



Entries 25426 
Mean 2.425e+04 
RMS 1.233e+04 
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Figure 3.28: Distribution of number of stars in an image (upper plot) and distribution of ratio 
of number of stars in an image to number of catalog stars in the observed field (lower plot) 
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Astrometry error distribution 
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Figure 3.29: Distribution of average astrometry error in an image 
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- for each star in ast file program finds a corresponding star in the 
reference catalog. In case it is found the field magcat is filled with the 
magnitude of the star from the reference catalog. Correction for this 
star is calculated as : 

Smag = magcat " mag^ (3.15) 

this is value which must be added to instrumental magnitude to obtain 
normalized one. Typically about 50% of ast stars have corresponding 
star in the currently used reference catalog (TYCHO). 

- after matching procedure, corrections values are known only for pixels 
where stars matched to catalog stars are present. In order to calculate 
correction for each star in the image, correction values are calculated 
for all pixels of the image by extrapolating values determined for ref- 
erence stars. Correction value C(x,y) for each pixel in the image is 
calculated as average of corrections for nearby reference stars weighted 
by distance to pixel where this star was observed : 

C{x,y)= Yl w{^{x-x,y + {y-y,y)-C^x„y,) (3.16) 

ref. stars ■.R<Rmax 

An example of resulting correction image is shown in Figure 13.301 

- normalized magnitude is calculated for every star in the image accord- 
ing to formula : 

magnorm = magcat + C{x, y) (3.17) 
where (x,y) are chip coordinates of the normalized star. 

• Stars from the ast file are matched to stars read from the database ( see 
step 3 ) and kept in the memory. In case given star is found on the list 
of stars kept in the memory, the star measurement from current ast file is 
linked to the list of measurements of this star. In case this star was not 
yet observed, it is added to the list of stars in the memory and fiagged as a 
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Figure 3.30: Correction image obtained in cataloging to normalize instrumental magnitudes to 
magnitudes of stars in the reference catalog. 
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new object in the catalog. After all stars in ast file are processed next ast 
file is read and process starts from the beginning ( step 1 ). The procedure 
continues until all ast files are processed. 

After the above steps all good quality data in ast files is saved to the database. 
However, there are several technical details which should be mentioned here. 
First of all, as can be seen in Figure [3^26] the Star table has statistical fields like 
magnitude, dispersion of magnitudo (sigma_mag), no_measurements which are 
not updated during data loading, but they are very useful in further data analysis. 
These fields are recalculated by pg/sql procedure ReCalcNight after the data is 
loaded to the database. The second step is optimization of the database, before 
loading of night ast files most of the indexes on tables Star and Measurements 
must be dropped in order to load data efficiently. After loading is finished these 
indexes are re-created. After loading new data its location on the disk must be re- 
organized in order to provide fast access. It is realized by PostgreSQL command 
CLUSTER. After all optimizations and recalculations are finished the database is 
unlocked and off-line algorithms can be executed on new night data. 

3.3.1.4 Efficiency, purity and precision of observations 

Efficiency and purity of reduction and cataloging was tested by the following pro- 
cedure : 

1. Initialization of database - star catalog database was initialized with stars 
from TYCHO-2 star catalog 

2. Initial stars were flagged as TYCHO-2 stars in the database 

3. Test data was loaded to catalog initialized with TYCHO-2 stars 

After this steps database was filled with data and there was an easy way to 
distinguish stars which are present in TYCHO-2 star catalog from those which are 
not and were observed only in "Pi of the Sky" images. The test was performed on 
two samples of images one from night 2007-04-25/26 taken with shutter in nor- 
mal mode and second sample were images from night 2007-05-12/13 taken with 
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shutter permanently opened. Total star identification efficiency which is defined 
as : 



_ NtyCH02/PI . . 

^n-red — — (^O.iOj 

^^TYCH02 

where Nj'ycho2/pi stands for number of TYCHO-2 stars identified by "Pi of 
the Sky" photometry and Ntycho2 is number of TYCHO-2 stars in the observed 
field. The Table [3^ shows total efficiencies for single image and set of images. 



Night 


Number of images 


Magnitude range 


Efficiency 


2007.04.25/ 


''26 


1 


- 12 


0.74 


2007.04.25/ 


/26 


41 


- 12 


0.84 


2007.04.25/ 


/26 


41 


- 15 


0.77 


2007.05.12/ 


/13 


1 


- 12 


0.78 


2007.05.12/ 


/13 


41 


- 12 


0.87 


2007.05.12/ 


/13 


41 


- 15 


0.82 



Table 3.9: Total efficiencies for night 2007.04.25/26 ( data collected with shutter in normal 
mode ) and 2007.05.12/13 ( data collected with permanently opened shutter ) 



The Figure 13.311 shows the efficiency of star identification in function of star 
brightness for data collected with permanently opened shutter ( 2007.05.12 ) and 
shutter in normal open/close mode ( 2007.04.25 ). 

The Figure 13.321 shows efficiency in function of number of field observations. 
It can be seen that at least 10 images of field must be catalogued before running 
nova identification algorithm and the safe limit is 20 exposures. This ensures that 
nova candidates will not be mainly due to normal faint stars added to catalog for 
the first time. The best way would be to initialize star catalog with all objects 
up to 12-13™, which is planned to be done. 

The Figures 13.331 and 13.341 show efficiency and background in function of chip 
coordinates. It is clear that efficiency and background drop in the corners of the 
CCD chip and reach the highest values in the center of the chip which is due to 
the fact that less light reaches corners of CCD because of properties of the optical 
system. 
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Figure 3.31: Efficiency of TYCHO-2 stars identification in function of magnitude for data 
collected during night 2007.04.25/26 with shutter in normal (open/close) mode (left plot ) and 
data collected with shutter permanently opened during night 2007.05.12/13 ( right plot ) 
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Figure 3.32: Average efficiency ( stars 0-12™ ) of TYCHO-2 stars identification in function 
of number of field observations for 3 different nights and after applying correction of shutter 
opened effect. 
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Figure 3.33: Efficiency of TYCHO-2 stars identification in function of star position (x,y) on the 
CCD chip. Left plot shows efficiency of single average of 20 images from night 2007.04.25/26 
collected with shutter in normal mode and right plot shows efficiency on single image from night 
2007.05.12/13 collected with permanently opened shutter 
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Figure 3.34: Number of observed objects not existing in TYCHO-2 catalog in function of star 
position (x,y) on the CCD chip. Left plot shows objects found on single average of 20 images 
from night 2007.04.25/26 collected with shutter in normal mode and right plot shows objects 
found on single image from night 2007.05.12/13 collected with permanently opened shutter 
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The situation is slightly more difficult in the case of purity determination. 
The objects in the TYCHO-2 star catalog are only stars. Objects observed by 
"Pi of the Sky" which are not present in the TYCHO-2 catalog are not only 
background events. They can be non-star objects like galaxies etc. However, 
after many observations of given field all objects in the range of the telescope 
should already be observed and new objects appearing in the catalog after many 
field observations can be considered as background ( assuming signal events are 
very seldom ). The Figure [3351 shows number of new objects added to star catalog 
on subsequent images of the same field and also total number of new objects in 
function of number of field observations is shown. The data presented on this 
plot was collected during night 2007.04.25/26 with shutter in normal open/close 
mode. The steps at frame id=40 and id=34 are due to trace of satellite ( or 
plane ) which is shown in Figure 13. 361 It is clear that after many ( >40 ) field 
observations number of new objects added to star catalog on every image is very 
small and equals few events per image, unless background event ( like satellite, 
plane etc ) is observed. For comparison the same plots for data collected on the 
same field with shutter permanently opened ( night 2007.05.12/13 ) is shown in 
Figure [3738l The conditions during both night were similar, the number of objects 
added to star catalog was much higher during night when data was collected with 
permanently opened shutter. 

Figure 13.371 shows cumulative number of events added to catalog in function 
of image number for couple of fields observed during many nights. These plots 
indicate that the minimum number of field observations to consider new objects 
as potential nova candidate is 20-30. 

In Figure [3739] results for field ( 0851-70 ) are shown, the number of background 
events added to catalog on every image is much larger. Most of these objects are 
artifacts coming from photometry of strip of charge which appears when images 
are collected with permanently opened shutter ( see Fig. 13.401 ). On field 0851-70 
number of stars ( 33000 ) is much higher then in field 0800+20 ( 18000 ) which 
causes much higher number of stars causing significant "open shutter" strips. 

Open shutter causes that charge is collected also in pixels above the readout 
pixel during chip readout ( Fig. 13.401 ). It is possible to reduce this effect by 
subtracting from every pixel fraction of values in pixels below. The image before 
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Figure 3.35: Number of new objects added to catalog on subsequent images (left plot) and total 
number of new objects added to catalog in function of image number right plot. The data was 
collected on field 0800+20 ( average number of stars 18000 ) during night 2007.04.25/26 with 
shutter in normal (open/close) mode 



and after the correction is sliown in Figure [3^401 Tiie correction is not perfect, but 
significantly reduces this effect. The data from night 2007.06.04/05 was corrected 
and cataloged, number of new objects in function of image number is shown in 
Figure [3.41[ The number of new objects in every image is reduced approximately 
by a factor of 2. 

The efficiency of star identification can be parameterized in function of number 
of stars in image. Figures 13.421 and 13.431 show star identification efficiency in 
function of number of stars in image for star catalog created from images averaged 
over 20 and star catalog created from single images ( respectively ) . These plots 
were obtained for single sky field 0800+20. 

However, as can be observed from Figures 13.421 and 13.431 this is not the best 
parametrization. Much better parametrization is efficiency in function of ratio 
Rcat, defined as : 
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Figure 3.36: The reason for step visible on previous image at frame id=34. Part of image 
without satellite (or plane) trace is visible on left image and with the trace on right image. 
This trace causes addition of new objects to star catalog 
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Figure 3.37: Number of new objects added to catalog from the beginning to given frame number. 
Data for different fields collected during many nights is shown. 
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Figure 3.38: Number of new objects added to catalog in function of number of images (left 
plot) and total number of new objects added to catalog in function of image number right 
plot. The data was collected on field 0800+20 ( average number of stars 18000 ) during night 
2007.05.12/13 with shutter permanently opened. 
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Figure 3.39: Number of new objects added to catalog on subsequent images (left plot) and 
total number of new objects added to catalog in function of image number right plot. Data 
was collected during night 2007.06.04/05 with permanently opened shutter, on field 0851-70 { 
average number of stars 33000 ) 




Figure 3.40: Image taken with permanently opened shutter before correction (left image) and 
after correction (right image) 
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Figure 3.41: Number of new objects added to catalog on subsequent images (left plot) and 
total number of new objects added to catalog in function of image number right plot. Data was 
collected during night 2007.06.04/05 with shutter with opened shutter, on field 0851-70 and 
correction of opened shutter effect was applied 
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Figure 3.42: Efficiency of star identification in function of number of stars in image for sky field 
0800+20. Star catalog obtained from images averaged over 20 
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where Nimage stars IS number of stars in image and Neat stars is number of 
stars found in reference catalog ( used in cataloging ) in the observed field. Star 
identification efficiency in function of ratio Rcat is show in Figure 13.441 this ef- 
ficiency was calculated for different sky fields and different nights. As expected 
this dependency is linear. The average efficiency of star identification on single 
10s exposure was determined by averaging efficiency from many single images 
collected during different nights ( every 25 image from single night was cataloged 
). The resulting average efficiency for stars of brightness 0-12™ is : 

estar ~ 0.49 (3.20) 

This number can be used to calculate total efficiency of the on-line flash 
recognition algorithm ( Sec. 13.2.41 ). Multiplication of efficiency of algorithm cuts 
determined as ecuts ~70% by efficiency of finding stars in image Cgtar ~50% gives 
the overall efficiency of the fiash recognition algorithm eon-iine ~35% ( for stars 
0-12"* ). It is larger for brighter stars and can reach nearly 70% for stars 0-10"*. 
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Figure 3.43: Efficiency of star identification in function of number of stars on single 10s image 

The precision of star brightness measurements can be determined by finding 
dispersion of magnitude measurements for individual stars and plotting dispersion 
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Figure 3.44: Efficiency of star identification in function of ratio Rcat 



in function of star brightness. Tlie Figure 13.451 shows distribution of dispersion 
in function of star brightness for stars observed during night 2007.06.06/07. 

3.3.2 Off-line algorithms 

Off-line algorithms act on data stored in the database. The data is cataloged in 
the way described in previous section and it is stored in tables frame, star and 
measurements. It is optimized for certain types of queries which are executed 
by analyzing programs. The algorithms described here have been implemented 
and tested on a star catalog created from images averaged over twenty - so called 
aver20 database. However, they can also be used to analyse the catalog of single 
images data. Two algorithms developed by author will be described. The first 
one looks for new objects appearing in the star catalog which correspond to new 
objects appearing in the sky. Such kind of processes may be due to nova stars 
explosions or other kinds of processes when object below detection limit suddenly 
increases its brightness and appears as a new object. The second algorithm looks 
for sudden increases of stars brightness, such events can occur in flare stars, but 
this can also happen in other objects like blasars or AGNs. In both cases rejection 
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Figure 3.45: Precision of star brightness measurements in the photometry on images obtained 
by averaging 20 single (10s) images. 
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of false event was the most important task. Both algorithms were implemented 
in perl scripting language. 

3.3.2.1 Nova identification algorithm 

This algorithm was developed to find new objects which were not present in the 
star catalog before. The algorithm is invoked for data collected during specified 
night. It performs the analysis of all new objects added to the catalog during 
analysed night. The objects which are expected to be found by this kind of al- 
gorithm are those which are normally below detection threshold of "Pi of the 
Sky" detector, but due to intrinsic reasons increase their brightness and become 
possible to be detected. The astrophysical processes can be nova star explo- 
sion, supernova or GRB, but it can also be a fiare star or even variable star of 
large amplitude of brightness variations. There is also large amount of back- 
ground processes which must be efficiently rejected. The algorithm relies on fiag 
Measurements .new_star which is filled during cataloging. This field is true for 
the record which is the first measurement of the object. The algorithm is realized 
by perl script do_flareevents.pl. The main steps of the algorithm are the 
following : 



1. connection to the database star catalog 

2. selection of fields which were observed during the given night and have total 
number of observations N^bsfieid > ^obsfieid ■ Only images from selected 
fields will be considered in next steps. 

3. every field selected in the previous step is analysed now. The first step is 
selection of all images of specific field from given night to list id_f rm_table 

4. images are verified against clouds and moonlight, average pixel value Pavg 
in the image is compared with the limit Tavg, calculated as : 

Tavg ^ Pavg ^ ~^-^avgcut ' ^avg (3.21) 
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values < Pavg > and aavg are obtained from distribution of average pixel 
values from all images collected so far. In case the image does not sat- 
isfy condition Pavg < Tavg it is rejected and skipped from further analysis. 
Cloudy images are also rejected in cataloging phase by condition imposed 
on the number of stars in image ( see Sec. 13.3.1.31 ). 

Every image from the analysed field kept in the array id_f rm_table is now 
analysed, and the following subsequent criteria are applied to every image : 



5. all measurements from an image, flagged as new object ( with Measurements . new_star 
= true ) are selected with additional conditions for brightness of the new 

object mag < magmin and for number of measurements Nobs > NJUT- Ev- 
ery object accepted by the above criteria is analysed as potential nova-like 
event and subsequent criteria are applied. 

6. verification of object in the second camera ( if available ) 

7. determination of the number of object observations during the given night 
( in case the second camera is not working this is the best indication of the 
event quality ) 

8. The event is checked if there is no nearby ( RKK^l^^^r ) '^^ry bright star ( 



magbigstar < magi;!^^^^^) in "Pi of the Sky" or TYCHO-2 [57| catalog. 



9. Despite the fact that the field was already observed at least N^lJ-^i^ times, 
it is possible ( most probably due to bad weather conditions or faintness of 
the object ) that it is just a normal star which remained undetected before. 
Thus every event is checked against the TYCHO catalog and in case a star 
of brightness mag < mag^^^^ found in distance R < B^sta-r° the event 
candidate is rejected. 

10. In case the image was collected with permanently opened shutter, an ad- 
ditional check for bright stars below and above ( in CCD y coordinate ) is 
performed. In case bright star ( mag < magabove ) is found in the same im- 
age in the column close to the event candidate column ( \Xf.vent ~ Xbigstar] < 
^-^bigstar )' ^hcu the cvcut Candidate is rejected. 



3.3 Off-line data analysis 



11. Event is verified against the list of known hot pixels, which are stored in 
database table HotPixels ( Fig. K26\ ) 

12. In case coordinates of the event are close to one of the Solar System planets 

it is rejected ( Dpianet < Rplanet ) 

13. Dispersions of mount tracking speeds are checked for each image. In case 
they exceed certain limit, the image is flagged as bad quality image ( shifted 
image ). Events found on such images are automatically rejected. 

All events which survived criteria 6) are saved to database table FlareEvents 
( Fig. 13.261 ). Later cuts do not reject events definitely, only rejection fiag field 
f l_rej_tycho is set in the database. Its value depends on the cut which rejected 
the event. Table [3?T0] lists possible values of rejection fiag. 



Rejection Flag Value 


Description 





accepted event 


1 


star found in TYCHO 


2 


nearby bright star found in TYCHO 


3 


saturated star found above event ( Ygtar > ^event ) 


4 


saturated star found below event ( Ygtar < Yevent ) 


5 


bright star found in "Pi of the Sky" star catalog 


6 


hot pixel 


7 


sky background level > Tavg 


8 


anti planets cut 


9 


image quality cut 



Table 3.10: Rejection flags values 



Events presentation is implemented in form of php script selecting events from 
the database. The additional difficulty is the fact that algorithm is executed on 
the remote server and results are originally saved to the remote database. The 
events data is copied to the local server ( Sec. 13.3.2.31 ) for convenience and 
also in order not to overuse the Internet link to LCO by direct accessing of the 
remote database multiple times. The synchronization is executed once and all 
later analysis and inspections of events are using events data from local server 
not from LCO which is much faster. 



3.3 Off-line data analysis 



Parameter 


Default Value 


Script option 


obs field 


50 


-min obs field 




11 


-mag 


iii'Uybiqstar 


8 


-near bigstar max mag 


TDmm 
bigstar 


15*36 [arcsec 






jjtycho 
^star 


150 [arcsec 




-near star radius arcsec 




13 


-max tycho star 


^„„above 
iii'Uy bigstar 


5 


-max bigstar above 


A vmax 
bigstar 


10 


-max_bigstar_x_dist 


^avgcut 


3 




Rplanet 


7200 [arcsec 




-reject_planets 



Table 3.11: Most important parameters of the nova identification algorithm 



The cataloging program stores measurements of 10^ - 10^ stars per night and 
flags new objects with special flag. The nova identification algorithm analysis 
stars from a given night and flagged as new objects in the catalog. Large part 
of the job is performed by the cataloging program, the algorithm itself analysis 
Nnew ~ 10^ — 10^ objects, which takes 1-3 hours. Figure 13.461 shows number of 
events after subsequent cuts for several nights. 

Efficiency of nova identification algorithm was tested. The following proce- 
dure was used, given number of stars ( typically 100 / image ) of given brightness 
were added to star catalog database. Algorithm was executed on data from night 
for which artificial stars with measurements were added. The number iV*^!;"* of 
generated and accepted events was determined and using this number efficiency 
was determined as : 



jaident 

(3.22) 

gen 



3.3 Off-line data analysis 



I Number of events after subsequent cuts | 




Figure 3.46: Number of events after subsequent cuts of nova identification algorithm. Results 
from five nights are shown. 

The Figure 13.471 shows efficiency for several subsequent nights. The best effi- 
ciencies were obtained when only 5 earlier observations of sky field were required. 
However, this is very small number of field observations and many weak objects 
still remain undetected. This implies large amount of background events, which 
can be seen in Figure I3.48[ The Figures 13.491 and 13.501 show efficiency losses on 
subsequent nights for different values of iVX/ieZd parameter. 

The Figure IXSTl shows efficiency in function of brightness of generated stars. 
It may be astonishing that it is independent of star magnitude, however, it is clear 
that it should not. The procedure described above tested only efficiency of sub- 
sequent cuts of the algorithm which does not depend on star brightness. The effi- 
ciency is different for different nights mainly due to differences in Moon phase and 
observed fields. Due to cut on number of field observations Notsfieid > ^dTfieid 
causing rejection of events generated in images of rarely observed fields. The best 
way to eliminate dependency of the efficiency on number of field observations 
would be to initialize star catalog with the complete catalog of objects match- 
ing the range of "Pi of the Sky" telescope ( 12-13'" ). Such a catalog should 
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Efficiency of nova identification aigorithm for different nights 
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Figure 3.47: Efficiency of nova identification algorithm for several nights. Different values of 
minimum number of field observations requirement were tested 
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Number of background events VS efficiency 
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Figure 3.48: Efficiency of nova identification algorithm vs number of background events from 
single night 



3.3 Off-line data analysis 



Number of generated events after subsequent cuts, N_obsfield_min=5 
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Figure 3.49: Efficiency losses on subsequent cuts of algorithm for different values of parameter 
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3.3 Off-line data analysis 



Number of generated events after subsequent cuts, N_obsfield_min=20 
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Figure 3.50: Efficiency losses on subsequent cuts of algorithm for different values of parameter 
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3.3 Off-line data analysis 



Efficiency of nova identification algorithm 
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Figure 3.51: Efficiency of nova identification algorithm for different brightness of object added to 
star catalog, tested for different nights (upper plot). The lower plot shows number of generated 
events after subsequent cuts. 



3.3 Off-line data analysis 



contain all types of objects ( star, galaxies etc ) in the range of the telescope. 
The overall efficiency of nova determination depends on the star brightness. This 
dependency is "hidden" in the photometry procedure. The efficiency of star iden- 
tification procedure was determined and described in Section I3.3.1.4[ The result 
of multiplication of photometry efficiency on single image ( result of average over 
20 ) in function of star brightness by average algorithm efficiency enova-aigo ~0.44 
is shown in Figure I3.52[ Comparison of efficiency losses on subsequent cuts for 
five nights is shown in Figure 13. 531 



Efficiency of nova aigoritfim on single aver20 image 
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Figure 3.52: Total efficiency of nova ( of brightness 0-12'" ) identification algorithm on single 
aver20 image ( resulting from averaging 20 single images ). 



Important result of the tests is determination of the amount of background 
events which must be verified daily. The Figure 13.48! shows number of back- 
ground events vs efficiency of the algorithm for several different values of N'^^Jj^^i^ 
parameter. The final values of the parameters allow to efficiently suppress the 
background so that number of events to checked does not exceed twenty events ( 
during clean sky night ). 



3.3 Off-line data analysis 




Figure 3.53: Comparison of efficiency losses on subsequent cuts for 5 nights. During night 
2007-05-29/30 the Moon was almost full and cut requiring low level of sky background rejected 
most of the generated events 



3.3 Off-line data analysis 



3.3.2.2 Flare identification algorithm 

This algorithm was developed to find outbursts of stars which are already in the 
database star catalog, but manifest sudden increase of brightness. The algorithm 
is executed on data collected during specified night, it is started after cataloging 
of new night is finished. Currently cataloging is performed on-line during data 
collection so analyzing script ( find_flares_all_nights.pl ) can be launched 
in the morning. The main steps of the algorithm are the following : 

1. Selection of stars brighter then magmin, observed during analysed night and 
having total number of measurements Nobs > 

2. Variability cut - star brightness range must satisfy condition : mag max — 
fno-guiN > Tmagdiff- The number of stars selected at this stage is of the 
order of 10^ — 10^. It depends on quality of the night data and on Tmagdiff 
parameter. This dependency is shown in Fig. I3.54[ 




Figure 3.54: Number of stars with magMAX — magMiN < Tmagdiff (left plot) and distribution 
of mag MAX ^niagM IN (right plot). Only stars satisfying condition on number of measurements 
are shown ( data from night 2007.05.26/27 ). 



For every selected star the following steps and criteria are performed 



3.3 Off-line data analysis 



3. Select measurements for given star 

4. Check if number of measurements for the given night N^l^^^ > N^^^^^^^ 

5. Find upper limit of the magnitude range magmax-, which is defined as max- 
imum value of magnitudo in the "last" non empty bin[l of magnitudo mea- 
surements distribution ( see Fig. 13.551 ) . In most cases the value magmax 
is the same as maximum magnitude measurement for given star. However, 
in some cases (e.g. due to clouds) real "last" non empty bin can contain 
few outliers and can be separated from most of the measurements ( see 
Fig. 13.561 ). In order to exclude those bad measurements, "last" non empty 
bin [M,M+AM] is chosen as the one before an empty bin and satisfying 
condition : 



N{mag <M + AM) > 50% ■ Kbs (3.23) 

The maximum magnitude is found in the "last" non empty bin and used as 
upper limit magmax- 

6. Find lower limit of magnitude magmin so that at least 85% of all magnitude 
measurements for given star belong to range {magmin, magmax) ( see Fig. 
13.551 ). Value of flare threshold is determined as Tfiare = f^o.gmim all points 
brighter then this value are considered as belonging to an outburst event. 

7. Find longest series of measurements with mag < Tfiare and require this set 
to have at least N^^^^ points 

8. Check maximum brightness measurement Mjjl^^'^ in the flare series and de- 
termine its time t^^"^*^ 

9. Verify if measurements within the series and before and after have the 
same chip coordinates (x,y), because due to calibration imperfectness star 
brightness measurements can vary with the star position on the chip, caus- 
ing background events with flare like signature ( visible as step on the light 
curve ) 

^in the direction of increasing magnitude 



3.3 Off-line data analysis 



10. If the data was collected with permanently opened shutter verify if there 
is no star brighter then magabove in the strip of AX^^j^^^ pixels from the 
analysed star. Opened shutter causes that column obtains additional signal 
from stars with Y <Yq and can generate background events. The rejection 
condition is the same as in described earlier nova identification algorithm. 

11. Check if there is no bright star nearby which could affect measurements of 
flare suspected star. In case a star brighter then rnagj}f^jj.^j. is closer then 
Rhigstar then cvcut is rejected. This condition is checked in the "Pi of the 
Sky" star catalog and also in TYCHO-2 (s?! star catalog 

12. Verify if brightness increase is not due to hotpixel. Chip coordinates (x,y) 
are verifled. The event is rejected if its (x,y) coordinates belong to a list of 
known CCD defects stored in the database table HotPixel ( Fig. 13.261 ). 

13. Peak height AMj^^^^ over the average brightness level is determined and 
flare event obtains quality flag according to this value, events with IS.M^'^^^ > 
0.4"^ obtain quality=l and those with AMj^^^^ > l.O'" obtain quality=2 

14. Finally event is accepted and saved to the database table FlareEvent with 
all information describing this event and calculated by the algorithm 

15. Sky background level in the image is checked in the same way as in nova 
identiflcation algorithm (Sec. 13.3.2.11) . 

Algorithm parameters are listed in Table I3.12[ 

Depending on the quality of the night, algorithm analysis Ngtar < 10^ stars 
which takes about 1-2 hours. Event numbers after subsequent cuts are shown in 
Figure [3371 

In order to determine efficiency of this algorithm fiare events were generated. 
Events were generated for specified night and analysed by the same script for 
fiare identification used for analysis of the real data. The simulation consists of 
the following main steps : 

• Certain number A^Jf^g of stars in the star catalog was selected ( specified 
by simulation parameter ) 
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Figure 3.55: Example of determined range of 85% of measurements points ( area between 
horizontal lines in the left plot ) and distribution of all measurements for the same star (right 
plot) 
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Figure 3.56: The distribution of magnitude measurements for a single star an argument why 
not maximum magnitude is used as upper limit magmax in the algorithm 



3.3 Off-line data analysis 



Parameter 


Default Value 


Script option 




30 


-min points 




12 [mag 




-mill mag star 


Tmagdif f 


0.5 [mag 




-min max mag limit 


minobs 


20 


-min night points 


jqjlare 
rain 


3 


-min_points_ab ove 


strip 
^(^9bicstar 


5 [mag] 


-max bigstar above 


strip 


10 [pixels] 


-max_bigstar_x_dist 


rnagJ^'Zar 


8 [mag] 


-near bigstar max mag 


Rbigstar 


15 [pixels] 


-near_bigstar_distance 



Table 3.12: Most important parameters of the flare identiflcation algorithm 




Figure 3.57: Number of events after subsequent cuts of the flare identiflcation algorithm. The 
data from flve nights is shown. 



3.3 Off-line data analysis 



• Time of flare start was randomly chosen from the series of measurements 
for a given night 

• Magnitude measurements after the starting time were replaced by values 
obtained from flare parametrization 

• Star with generated points added was analysed and accepted or rejected by 
the algorithm 

In order to simulate flare-like outburst simple linear/exponential parametriza- 
tion was fltted to real flare detected by the algorithm ( see Section 14.31 ) : 

/ mo - F^ax - XT for t < At 

"^"^ = 1 mo - F_ . exp [-^] for t > At (3.24) 

These parametrization is presented in Figure 13.581 
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Figure 3.58: Linear/Exponential parametrization of the flare-like outburst. Fit was performed 
to real flare star GJ 3331A / GJ 3332 outburst which occurred on 2006.11.28 06:03 UT 

Examples of generated flare light curves are shown in Figure I3.59[ Flare 
identiflcation efficiency was tested in function of 4 parameters used to describe 
the flare GJ3331A/GJ3332 in fitted parametrization. 

The results of these tests are shown in Figure 13.601 
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Figure 3.59: Example of light curves with generated flare with outburst peak of 1™ above 
average brightness level (left plot) and decay time of 200 sec (right plot), other parameters of 
the light curves are the same as those fitted to GJ3331A/GJ3332 outburst 



3.3.2.3 Data synchronization and presentation 

The cataloging and data analysis are performed on the remote server. In the 
prototype version it is performed on pil, pi2 and pi3 computers at LCO. In 
order not to overuse the bandwidth only the final results are once copied to local 
server in Warsaw. It is impossible to synchronize the entire database because it 
is too large. However, results of algorithms can be synchronized with light curves 
of corresponding stars. There is also possibility to specify interesting objects 
which light curves should also be synchronized. After synchronization data is 
stored in the local database which is accessible from the command line and script 
level, but also through the WWW php interface. Results of on-line algorithms are 
synchronized on-line during a night. Besides database information also subrenders 
of the sky images containing events are copied to local server allowing for quick 
verification of event candidates. They are also available through the WWW 
interface. 
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Figure 3.60: Efficiency of flare identification in function of outburst amplitude (left upper plot), 
rise time (right upper), decay time (left bottom), star average magnitude (right bottom) 



3.4 Periods when algorithms were working 



3.4 Periods when algorithms were working 

Before showing the resuhs of the algorithms it is important to mention that not 
all algorithms were used during the full time of the prototype work. Table 14.11 
shows periods and configurations in which the prototype was working. Because 
of technical problems shown in this table coincidence algorithm could not work 
for all the time. Also not all the algorithms were ready to be used since the very 
beginning. Table 13.131 shows which algorithms were used in what periods. Some 
algorithms could also be run off-line, but large amount of events could not be 
verified. Currently all off-line algorithms are working and events are systemati- 
cally checked after each night. 



Algorithm Type 


Working Periods 


Notes 


On-line coincidence 


2004.06.25 - 2005.03.01 , 
2006.05.20 - 2006.08.08 


two cameras 


On-line confirmation on next image 


2005.03.12 - 2005.08.09 , 
2006.05.20 - 


single camera 


Off-line nova on aver20 


2006.07.21 - 




Off-line flare on aver20 


2006.07.21 - 





Table 3.13: Periods in which different algorithms were used 



Chapter 4 
Results 

4.1 Data from the prototype system 

Data from the prototype system have been collected in the time period from June 
2004 until now ( 22 October 2007 ) with 9 months break due to maintenance 
reasons. During this period the system collected data from 738 nights which 
is ~80% of nights in the period when system was operational. The remaining 
20% was lost mainly due to clouds or some minor system failures which could be 
remotely solved after few hours or days. Table 14.11 lists data collection periods 
with description of major problems in the system. 

The observation time was calculated using the image information saved in 
the database. The Table 14.21 shows observation times for two versions of the 
prototype. This times were normalized to in coverage. In the first period all 
sky images from nights with at least 100 images were taken into account, in the 
second period additional cut on number of stars on image Ngtars > 1000 was 
imposed in order to ignore cloudy data. This cut could not be used for the first 
period because this information was added to the database during the system 
upgrade. 

4.2 Optical flashes in 10s and 22s timescales 

Every night when the system was running, the flash identification algorithm was 
looking for optical flashes on-line. The final results of the algorithm were verified 
by a person on duty and events which could not be rejected by any criteria were 



4.2 Optical flashes in 10s and 22s timescales 



Start Date 


End Date 


Period Description 


20040625 


20050120 


both cameras k2a and k2b working correctly 


20050120 




problems with k2b power supply and cooling 


20050223 




k2b mostly not working 


20050419 




k2b shutter mechanism broken, data collected with 
opened shutter 


20050702 


20050809 


k2a cooling definitely broken, implies large noise 


20050810 


20060520 


system down due to maintenance reasons 


20060520 


20060808 


system working alter cameras repair and upgrade, 
both cameras working 


20060809 




k2b camera broken due to electricity problems in 
LCO, since then system works only with k2a cam- 
era 



Table 4.1: Data collection periods of the prototype, with crucial moments of major failures 
listed 



Time Period 


Normalized observation 
time [days] 


Lenses 


2004.06.23 - 2005.08.09 


2.04 


Carl Zeiss f=50mm 


2006.05.20 - 2007.08.28 


0.78 


Canon f=85mm 



Table 4.2: Data collection periods of the prototype, with crucial moments of major failures 
Hsted 



4.2 Optical flashes in 10s and 22s timescales 



flagged as "flashes". The statistics of all optical flashes detected by the prototype 
is shown in Table I4.3[ Most of the flashes were visible in a single 10s exposure 
in both cameras. AH these events are listed in Tables 14.61 14.51 and 14.41 They 
contain also the Dcone value ( Sec. 13.2.61 ). However, none of the events has this 
value sufficiently large to confirm astrophysical origin of the flash. There are a 
few events which were observed on two consecutive images, but only by a single 
camera ( when the second was not operational ). They are listed in Table [4?7l In 
this case also limit of distance Dmove derived from constant position of the flash 
is shown ( Sec. 13.2.61 ). 



Period 


Algorithm 


Number 
of flashes 


Exposure 

Time 

[days] 


2006.05.20 - 2007.08.28 


Confirmation on next 
image 


1 


0.78 


2006.05.20 - 2006.08.22 


Coincidence 


35 


0.14 


2004.06.25 - 2005.08.09 


Coincidence 


90 


1.68 


2004.06.25 - 2005.08.09 


Confirmation on next 
image 


5 


0.8 


2006.07.21 - 2007.09.06 


l^lash identification in 
240 sec timescale 





0.69 



Table 4.3: Statistics of optical flashes detected by the prototype 

In one case the flash was unambiguously identified as known astrophysical ob- 
ject. This event occurred on 2005.04.02 1:13:40 UT , it is presented in Figure [441 
It was identified as an outburst of the flare star CN Leo (RA = 10''56™29^ Dec = 
+7°0r). The light curve of this flash is shown in Figure [45l The normal bright- 
ness of this star, being m=13.5'", increased ~ 100 times reaching rrimax = 9™. 
The star was below the limiting magnitude of the telescope before the explosion 
and suddenly appeared as a new object. The signature of the outburst was clearly 
the flash-like signature which allowed for on-line algorithm to identify it. The ex- 
ample of an outburst visible in more then one image is shown in Figure [43l This 
outburst has not been assigned to any known source. 

All other flash events have been analysed. For some of them possible spa- 
tial coincidence with known astrophysical objects was found as shown in the 



4.2 Optical flashes in 10s and 22s timescales 





UT Time 


R,A 


Dec 


Dcone 


Mmax 


coincidirig ^.l^rf^s ^ sou]?c€s 


2006.07.25 


07:21:27 


18h39m03.14s 


-10"37'43" 


26878 


10.49 




2006.07.20 


07:24:02 


18h41m08.83s 


-10"43'39" 


31843 


9.78 




2006.07.17 


06:17:16 


18h22m42.46s 


-12"00'06" 


26099 






2006.07.17 


04:48:47 


23h66ml3.09s 


-23"62'06" 


11976 


10.1 




2006.07.17 


03:46:37 


19hl8m36.07s 


-10"60'06" 


34274 


8.8 




2006.07.17 


00:66:36 


12hl2ml6.84s 


-66"13'37" 


7697 


10.7 




2006.07.16 


06:67:24 


19h42m01.64s 


-09"26'64" 


37746 


10.6 




2006.07.16 


03:01:12 


18h24m02.21s 


-11"66'63" 


18370 


10.1 




2006.07.14 


07:29:28 


18h46ml3.81s 


-10"48'66" 


39694 


10.2 




2006.07.10 


04:61:00 


20h06m44.80s 


-10"08'06" 


29064 


9.04 




2006.07.10 


00:18:02 


12h42m62.66s 


22°36'27" 


6981 


10.81 


<1 arcmm Irom t^liV^- 
0444065 - Galaxy, 1 arcmin from 
FIRST J124239. 4 + 223536 - Radio- 


2006.07.03 


08:42:04 


01h02m50.01s 


04"29'27" 


7380 


9.76 




2006.07.02 


09:48:68 


00h40m30.20s 


04"00'26" 


6832 


9.6 




2006.07.02 


08:16:12 


01h42m27.20s 


09"34'42" 


7413 


10.46 




2006.06.29 


22:68:34 


Ilh40m20.20s 


13"34'68" 


6631 


11.37 




2006.06.29 


22:49:16 


Ilh38ml8.76s 


11"60'08" 


6493 


8.06 




2006.06.27 


03:19:64 


16hl0m39.49s 


-11"14'39" 


14128 


11.17 




2006.06.27 


02:24:34 


18h04ml6.33s 


-08"04'16" 


24909 






2006.06.27 


02:19:66 


17h69m66.77s 


-07"66'07" 


23460 






2006.06.26 


03:61:28 


16h39m03.76s 


-11"40'66" 


17909 


11.11 




2006.06.24 


02:47:18 


16hl6m34.48s 


-37"06'22" 


13788 


10.81 




2006.06.23 


09:13:04 


23h41m41.96s 


00° 01 '38" 


7174 




T arcsec from J2a4ia5.2-00014b 
Seyfert 1 Galaxy 


2006.06.18 


04:19:38 


19h20m32.60s 


-31"07'60" 


22918 


10.1 




2006.06.14 


09:48:41 


22hl7m47.86s 


-06"26'64" 


6873 


9.7 




2006.06.13 


07:38:68 


22h24m32.22s 


-07"17'11" 


8471 


9.26 




2006.06.12 


07:63:49 


22h01m06.08s 


-10"47'12" 


8406 


10.6 




2006.06.11 


00:03:36 


09h69m22.93s 


00''29'16" 


6937 


8.7 


1 arcmin from [LPZ94J 279 - Radio- 


2006.06.10 


04:67:63 


18h32m04.61s 


-10"04'08" 


21981 


8.93 




2006.06.08 


07:44:44 


17h31m64.42s 


-11°02'14" 


22002 


8.6 


2 arcmin trom IRAS 17291-1057 - 
Tnfra-RpH tiniirrp 


2006.06.08 


06:08:36 


17h44m26.43s 


-17"24'02" 


30666 






2006.06.06 


07:20:08 


17h41m41.34s 


-62"07'67" 


11407 






2006.06.06 


00:67:09 


12hl6ml4.43s 


-20"19'19" 


7969 






2006.06.01 


03:61:14 


12h49m26.68s 


13°17'64" 


10776 




1 arcmm trom i^'lRS'i' 
J124926. 0+131612 - Radio-source 


2006.06.22 


06:21:26 


16h39m21.26s 


-09"36'11" 


29140 






2006.06.21 


06:06:28 


16h38m06.76s 


12"49'19" 


18606 







Table 4.4: Optical flashes identified by the on-line algorithm since June 2006 requiring coinci- 
dence of fiash on 2 cameras. These fiashes were observed on single 10s exposure 



4.2 Optical flashes in 10s and 22s timescales 



Date 


UT Time 


RA 


Dec 




Mm, a, a; 


coinciding alerts / sources 


ZUUO.UO.Ui 


9^. ^Q. 1 6 




-41" 49' 


8444 




1 Vo T n 1 

3, nor "working 


ZUUJ.UO.U/ 


nfi. ^9. ^9 


91 Vi ^Qm 9nc 


-1 1" 62' 


21841 


7 1 ('?'! 


Ic^ 3, not "working 


ZUUO.UO.Ui 


nn.91 .49 


1 QVi 97tti 99fl 

±!7llZ I IIlZZo 


-23" 62' 


7833 


S S('?'l 
o-ol. ■ ^ 


2 9, not "working 




ni ■ ^fi.9^ 

U ± . lJU . Z i} 


1 7Vi4nTn4^c 


-|-14" 22' 


9362 


8 06 




zuuo.uu.ou 


nQ.^Q.^R 


1 QVin9TTi ^Rfl 


-18" 40' 


1 1784 


9 8 




9nnf^ OR n9 
zuuo.uo.uz 


Uo .oo . lo 


1 11i49inf^1o 
±±I11Z1110±& 


"t-Ol " 67' 





— — 




ZUUO.UD.Ul 


23 "34 ■ 14 


191i4lTn14o 
±ZI11±IIl±1t) 


-|-10" 44' 






1 Q i-r-ni in frnm C T? V) C _L11 ("'alavi' 
IdjlCIIlin IlOIIl \^ IXjLJ — r ± ± *4 LjrtiitiXy 


ZUUO.UD.Ul 




1 91in9in94o 

iznuziiizit) 


-j- 12" 49' 


rKK^ 


— TTTfT^ — 




ZUUO.UD.Ul 


m .47. 




-|-01 " 28 ' 


9983 


— rri — 




2005.06.01 


00: 19:37 


12h66ml9s 


-t-14"21' 


7486 


9.0 




2006.06.31 


22:66:16 


12h23m32s 


-|-11"49' 


6672 


10.0 


J122331. 1 + 114762 radio 


2006.06.31 


04:12:62 


Ilh68m61s 


-02"02' 


10671 


11.0 


Konus 4:27:26 


2006.06.31 


00:01:46 


Ilh64m62s 


-|-16"07' 


7111 


9.3 




2006.06.27 


23:02:13 


10hl6ml3s 


-|-14"20' 


6671 


10.9 




2006.06.27 


22:66:12 


10h62m40s 


-|-28"37' 


6637 


10.0 




2006.06.27 


22:63:34 


10h61m3s 


-|-24"42' 


6631 


7.2 




2006.06.27 


06:36:11 


16h66m42s 


-10"27' 


29060 


10.0 




2006.06.26 


03:67:10 


16h01m30s 


-08"01' 


36601 


10.0 




2006.06.20 


08:33:30 


16h33m61s 


-32"21' 


18299 


12. 0(?) 




2006.06.16 


23:04:60 


13h39m42s 


-39" 34' 


6660 


10.1 




2006.06.14 


03:28:22 


13h28m41s 


-16"67' 


16960 


9.3 




2006.06.14 


03:19:27 


13hl8m46s 


-21"30' 


14734 


10.3 




2006.06.14 


02:36:02 


13h33m67s 


-27"26' 


13338 


10.6 




2006.06.12 


04:69:08 


12h47m39s 


-|-10"24' 


14674 


8.9 




2006.06.11 


03:06:60 


Ilhl3m34s 


+ 12"16' 


10060 


8.6 




2006.06.06 


06:63:02 


14h02ml3s 


-|-00"36' 


28414 


8.6(?) 




2006.06.01 


10:09:26 


18h49ml6s 


+09" 17' 


6672 






2006.04.24 


06:24:24 


16h48m39s 


-10"18' 


11779 


9.1 




2006.04.01 


06:12:62 


Ilhl6m47s 


+ 06"69' 


26486 


10.2 


GSC 00269-00778 


2006.03.30 


04:46:08 


Ilh00m03s 


-|-14"38' 


19964 


8.9 




2006.02.16 


00:32:49 


lOhOOmlOs 


-13"16' 


6746 


8.3 




2006.02.16 


08:01:64 


10h08ml7s 


-|-13"10' 


23623 


8.4 




2006.02.16 


04:64:47 


llhOOmlOs 


-1-06" 16' 


17082 


9.0 




2006.02.12 


03:24:46 


09h46m31s 


-14"43' 


9816 


9.3 




2006.02.04 


07:07:33 


09h61m46s 


-|-12"19' 


12323 


9.6 




2006.01.31 


00:36:47 


07h00mlls 


-|-11"37' 


6667 


9.2 




2006.01.28 


07:09:06 


06h48m39s 


-|-13"23' 


17646 


9.6 




2006.01.17 


04:01:01 


08h49m00s 


+ 17"12' 


21937 


9.0 




2006.01.10 


00:64:16 


06hl0m31s 


+ 13"40' 


6626 


9.7 




2006.01.09 


02:23:36 


06h68m63s 


+ 17"11' 


10701 


9.26 




2006.01.07 


02:62:60 


06h02m36s 


+09"06' 


8640 


11.0 




2006.01.03 


06:34:48 


07h69m66s 


18"00' 


10160 


6.3 




2006.01.02 


06:41:28 


06h69m41s 


+20"63' 


30461 


8.9 


Konus+Integral 6:27:27 



Table 4.5: Optical flashes identifled by the on-line algorithm in 2005 requiring coincidence of 
flash on 2 cameras. These flashes "were observed on single 10s exposure 



4.2 Optical flashes in 10s and 22s timescales 



Date 


UX Time 


R,A 


Dec 






coinciding alerts / sources 


2004.12.27 


07:22:21 


05h48m30s 


00" 00' 


8074 


9.2 




2004.12.27 


03:51:03 


04h49m40s 


+ 19"58' 


11532 


9.8 




2004.12.22 


02:22:12 


07h07m03s 


+ 17"41' 


20514 


9.3 




2004.12.20 


02:24:46 


05h56m24s 


+03" 10' 


8344 


9.3 




2004.12.19 


02:46:43 


05h03m58s 


+07"34' 


8624 


9.9 




2004.12.18 


05:53:37 


05h48m38s 


+ 12"26' 


11325 


12.00 




2004.12.14 


02:29:21 


05h32m09s 


+ 14"29' 


11375 


9.1 




2004.12.11 


00:47:21 


03hl3ml4s 


+06"09' 


6641 


9.8 




2004.12.04 


07:34:46 


05hl9m21s 


+ 14"34' 


7945 


10.3 




2004.12.04 


06:28:54 


05h05m28s 


+21"15' 


18084 


11.2 




2004.12.04 


02:05:22 


03h01m51s 


+05"57' 


7689 


9.7 


galaxy [ZHG90] 0259-1-0545 


2004.12.02 


05:13:41 


04h07m24s 


+20"27' 


35734 


9.6 




2004.12.01 


01:28:47 


01h34ml9s 


+ 14"51' 


7123 


9.8 




2004.11.30 


04:09:42 


03h21m04s 


+ 19"01' 


15993 


11. 5(?) 




2004.11.28 


04:27:16 


01h27m28s 


+ 10"48' 


10041 


9.6 




2004.11.28 


03:20:15 


03h04m44s 


+05"42' 


9502 


7.5 




2004.11.26 


05:58:15 


05hl0ml2s 


+ 14"40' 


11028 


9.7 




2004.11.24 


07:39:33 


06h54m30s 


+ 18"49' 


7145 


9.7 




2004.11.23 


02:39:10 


05hl4m29s 


-07" 06' 


9111 


10. 0(?) 




2004.11.19 


00:53:08 


03hl4m50s 


-|-03"20' 


7166 


9.2 




2004.11.18 


07:53:55 


04h22ml3s 


-|-12"31' 


7505 


10.5 




2004.11.18 


01:36:09 


03hl0m22s 


-|-03"12' 


8120 


9.0 




2004.11.18 


00:25:36 


01h30ml7s 


-|-11"44' 


6655 


8.9(?) 




2004.11.17 


03:31:17 


02h48m36s 


-|-11"13' 


13252 


11.00 




2004.11.12 


02:51:31 


02h27ml2s 


-|-22"06' 


23387 


10.8 




2004.11.11 


04:46:43 


02h08m07s 


-|-10"13' 


16192 


10.7 




2004.11.11 


01:57:49 


04h03m47s 


-|-18"33' 


39317 


10.0 




2004.11.06 


06:02:58 


03h47m24s 


-|-10"22' 


12005 


9.0 




2004.11.05 


07:49:20 


02h34m32s 


-|-05"47' 


9813 


8.8 




2004.11.03 


01:22:40 


00hl2m32s 


-|-00"49' 


7483 


9.7 


Konus 1:26:43, Integral 1:27:11 


2004.11.02 


07:14:15 


01h23m53s 


-|-01"13' 


13855 


8.6 


Konus 7:27:56 


2004.11.01 


05:49:34 


23h47m44s 


-04" 23' 


10894 


9.6 




2004.11.01 


05:22:28 


23h20m39s 


-05"43' 


10147 


10.4 




2004.10.31 


06:15:37 


23h24m40s 


-01" 12' 


11215 


10.2 




2004.10.30 


05:22:06 


00h42m54s 


-29"30' 


9094 


9.0(7/9.4) 




2004.10.28 


05:56:42 


03h34m40s 


-08" 15' 


11525 


9.8 




2004.10.24 


03:40:00 


00h36m31s 


-05" 10' 


11388 


10.3 


Radio-source Cul 0034-054 


2004.10.21 


02:36:00 


01h02ml6s 


-04" 17' 


11101 


10.0 




2004.10.11 


07:37:09 


03hl2m08s 


-|-10"39' 


8485 


8.6 




2004.10.11 


06:15:13 


02h54m57s 


-|-18"16' 


13332 


9.8 




2004.10.05 


04:18:40 


01h24m04s 


-|-14"17' 


41061 


9.9 




2004.10.02 


02:20:50 


23h05m26s 


-|-12"36' 


13431 


9.9 




2004.10.01 


04:09:12 


21h46m26s 


-08" 18' 


11642 


10.3 




2004.09.30 


00:49:38 


23hl9m50s 


-02"36' 


8308 


8.5 




2004.09.27 


04:20:55 


03h29m33s 


-|-14"08' 


12965 


10.0 




2004.09.17 


03:50:25 


23h42m55s 


-|-31"44' 


20126 


8.4 




2004.09.13 


03:33:52 


00hl4m45s 


-|-02"50' 


40744 







Table 4.6: Optical flashes identifled by the on-line algorithm in 2004 requiring coincidence of 
flash on 2 cameras. These flashes were observed on single 10s exposure 



ID 


Date 


UT Time 


RA 


Dec 


DcoTie[km] 






hjxternal Alerts or 


7 


2006.10.10 


02:44:43 


00h8m57.80s 


34"51' 


18582 


108964 


11.7 




6 


2005.06.03 


06:29:57 


19h37ml4s 


-50°47' 


11616 


47268 


10.5 


Konus 6:29:01, excl. by 


5 


2005.05.31 


04:33:17 


17h43m48s 


-19°55' 


28323 


60048 


6.1 


konus 4:27:26, excl. by 
IPN 


4 


2005.04.16 


00:49:59 


llh03mlls 


11"06' 


8119 


108964 


10.5 


SN2003L NGC3506 


3 


2005.04.04 


05:37:59 


Ilh49m37s 


-05°31' 


30853 


108964 


10.3 


UaC 049a7-00794or LCttti 
B114710.1-051705or IRXS 
.1114951.0-053041 


2 


2005.04.02 


01:13:42 


10h56m29s 


-|-07"02' 


9082 




9.0 


V* CN Leo - flare star 


1 


2005.03.31 


01:36:46 


Ilh52m53s 


-05°59' 


12797 


108964 


10.0 


several galaxies or (jyc 
04938-00378 



Table 4.7: Optical flashes identifled by the on-line algorithm requiring signal at least on 2 
consecutive images. Events 5 and 6 are probably due to satellites. Value of Dmove in most 
cases was calculated for aarcsec=36" corresponding angular size of 1 pixel. 



4.2 Optical flashes in 10s and 22s timescales 



EVENTS FROM ALGORITHM REQUIRING COINCIDENCE ON BOTH CAMERAS 



2004.09.13-2005.08.07 
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ft * / 


■ 
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EVENTS FROM ALGORITHM REQUIRING CONFIRMATION ON NEXT IMAGE 

2005.03.12 -2005.08.07 
2006.06.01-2007.08.28 
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EVENTS FROM ALGORITHM REQUIRING COINCIDENCE ON BOTH CAMERAS 



2005.05.21- 2006.07.25 




ECLIPTIC IN GALACTIC COORDINATES 




Figure 4.1: Flashes detected by the "Pi of the Sky" system. The spatial distribution is shown 
in the galactic coordinates. Events from period 2004/2005 are collected near ecliptic plane due 
to HETE-2 pointing to anti-solar point 



4.2 Optical flashes in 10s and 22s timescales 
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Figure 4.2: Light curves of flashes visible on at least 2 consecutive 10s exposures 



4.2 Optical flashes in 10s and 22s timescales 




Figure 4.3: Optical flash visible on 2 consecutive images ( 4 and 5 ) on 2006-10-10 02:44:43 




Figure 4.4: Images of CN Leo outburst ( begins at image 4 ) 



4.2 Optical flashes in 10s and 22s timescales 
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Figure 4.5: Light curve of outburst of flare star CN Leo identifled by flash recognition algorithm 
on 2005.04.02 1:13:40 UT 



4.3 Outbursts in 240s timescale 



Tables 14.41 14.51 14.61 and 14.71 The condition for coincidence was an angular dis- 
tance of the flash event to the object Rcoinc<'2'- This is not a strict condition 
and coincidence candidates should be treated only as an indication. No evident 
coincidence with known GRB event was found. 

4.3 Outbursts in 240s timescale 

The off-line algorithms working on 20 averaged images were not implemented from 
the very beginning of run of the prototype. A part of the archival data has been 
analysed and checked, but the amount was too high to inspect all events. Since 
June 2006 these procedure is performed nightly and the results are inspected after 
every night. In this period flare identiflcation algorithm identifled a single flare 
event which occurred on 2006.11.28 06:03 UT and was identifled as an outburst 
of flare star GJ 3331A / GJ 3332 (RA = 05'*06'"50^ Dec = -2r35' ). The 
light curves of this flare are shown in Figures 14.61 and I4.7[ In this case the star 
was already present in the "Pi of the Sky" star catalog and the algorithm found 
sudden increase of its brightness. The star has risen by Am=0.55™ from m=9.58 
to m^ax = 9.03. 

The off-line algorithm looking for objects with nova-like signature didn't flnd 
any interesting astrophysical event. 

The only events of astronomical origin detected by this algorithm were back- 
ground events caused by known asteroids. They orbit the Sun and every night 
can be observed in different position, thus they are automatically being cataloged 
as new objects in the star catalog and found by the algorithm. The algorithm 
identifled 104 events related to asteroids ( till 2007.10.22 ). They turned out to 
be a good tool for testing the algorithm performance. Example of the asteroid 
detected by the prototype is shown in Figure 14.81 In the future version of the 
algorithm known asteroids will be rejected automatically. 

The total amount of data analysed by this algorithm normalized to An coverage 
is ^ 0.72 days ( till 2007.10.22 ). 



4.3 Outbursts in 240s timescale 



V 9 



o)9,1 \- 



9.2 
9.3 
9.4 
9.5 
9.6 



X 



X 
X 

X 

X 

X 



J I I I I I I I I I I I I I I I I I I I I I I I I I I I I I L 



50 100 150 200 250 300 350 

Time [minutes] 



Figure 4.6: Light curve of outburst of flare star GJ 3331A / GJ 3332 in 240s time resolution 
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Figure 4.7: Light curve of outburst of flare star GJ 3331A / GJ 3332 in 10s time resolution 
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Figure 4.8: Observations of asteroid Papagena in time period from 2007-02-20 to 2007-02-24 
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4.4 GRB observation results 

The main goal of the "Pi of the Sky" project are detections of the optical coun- 
terparts of GRBs. The prototype was not able to cover the whole FOV of any 
of the satellites observing in 7-rays. This strongly limited the chances to observe 
GRBs during 7 emission. According to our observing strategy ( Sec. 12.2.2.71 ) 
in the first period the system followed the FOV of the HETE satellite and since 
June 2006 the SWlFT's FOV was observed. The Table 14.81 shows statistics of 
GRB observations for these two periods. 



Period 


Apparatus 
OfT 


Morth 
hemi- 
sphere 


Daytime 


Below 
horizon 


Clouds 


Outside 
FOV 


Inside 
FOV 


Total 


2004.07.01 - 2006.08.09 


1 


18 


40 


8 


4 


16 


2 


89 


2006.05.20 - 2007.10.22 


9 


5 


70 


31 


7 


19 


1 


142 



Table 4.8: GRB observations statistics in period from 2004.07.01 to 2005.08.09 and since 
2006.05.20 



Only 24 GRBs occurred during the night and within the range of the telescope. 
All GRB events observed by the prototype are listed in Table 14.91 In two cases 
the GRB position was observed before, during and after the GRB. The total time 
of the prototype observations normalized to in is Ttotai ~ 2 days, assuming 2-3 
GRB occurring every night this means that on average 4-6 GRB events should 
occur in the prototype's FOV in the whole period, which is in agreement with 
the observed 3 events. 



GRB 


Alert Source 


Reaction Time [sec] 


Magnitude/Upper Limit 


z 


GCN Circular 


GRB070913 


SWIFT 


110 


>12.6"' 






GRB070B21 


SWIFT 


<o 


>12.5"' 


0.553 


GCN6437 


GRB070126 


SWIFT 


180 


>13.0"' ( 1 image ) 






GRB061202 


SWIFT 


170 


>14.3"' ( 10 images ) 




GCN5891 


GRB060719 


SWIFT 


65 


>12.8"' 




GCN5346 


GRB060607 


SWIFT 


124 


>13.4"' 


3.082 


GCN5241 


GRB060607 


SWIFT 


60 


>12.5"' 




GCN3526 


GRB050522 


INTEGRAL 


75 


>11.0"' 






GRB0S0412 


SWIFT 


<o 


>11.5™ 




GCN3240 


GRB040916 


HETE 


1020 


>13.0'" 




GCN2725 


GRB040823A 


HETE 


<o 


>10.0"' 




GCN2677 



Table 4.9: Early observations of GRBs performed by the prototype in period 2004-2007. When 
it is not explicitly written the limit was determined on 20 co-added images. 



Early detection of an optical counterpart of a GRB is not an easy task. Among 
a few thousands of already detected GRB events only about 25 events have optical 



4.4 GRB observation results 



counterparts observed during the first 60 seconds after tfie GRB trigger ( Tab. 
14.101 ). A number of early observations ( Tots < 60s ) without positive detection is 
not much larger, it is around 100 events. There are only 16 optical observations 
of GRB position started before and performed during the 7 emission, they are 
listed in the Table [4TT1 Three of such observations were performed by the "Pi 
of the Sky" system and are presented in this thesis. 



GRB 


Telescope 


jrLedciioii 

J. llllfr lotrcj 


Magnitude 


GCN Circular 


QQni 9'? 

yyuizo 
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ZZ 


1 1 89 / 8 Qf^ 1 

ii.oz / o.yo_ 


T ATTP71 nn 1 
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R A PTOR 


i iO 


iy.^ (^noi buiej 


VcrV^iN ZOOy 


uouoiy 


RnTQP TTT 


97 
z / 


1 

iU 






RnTQP TTT 


00 


1 7 
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OVVir 1 / V V \J 1 


DU 
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U(ji luy 
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■^9 
oz 


1 1^ 4 


nr'N/191 1 

VjV^i >l ^Z 1 1 


051111 


ROTSE-III 


27 


13.0 


GCN4247 


060110 


RAPTOR 


7 


16.1 


GCN4474 


060111B 


TAROT 


28 


13.8 


GCN4495 


060206 


SWIFT-UVOT 


58 


16.7 


GCN4684 


060210 


KAIT 


60 


18.1 


GCN4727 


060418 


PROMPT 


40 


15.3 


GCN4971 


060526 


WATCHER 


60 


15 


GCN5165 


060904B 


ROTSE-III 


19 


17.8 


GCN5504 


060926 


SWIFT-UVOT 


57 


19.0 


GCN5625 


060927 


ROTSE-III 


17 


16.5 


GCN5629 


061007 


ROTSE-III 


26 


13.6 


GCN5706 


061025 


ROTSE-III 


45 


15.6 


GCN5759 


061126 


RAPTOR 


21 


12.3 


GCN5873 


070610 


OPTIMA-Burst 


57 


19 


GCN6492 


070721B 


SWIFT-UVOT 


50 


15.9 


GCN6641 


070808 


ROTSE-III 


29 


16.2 


GCN6719 


071003 


KAIT 


42 


12.83 


GCN6844 



Table 4. TO: Positive early ( Tobs < 60 sec ) detections of optical counterparts of GRBs 



Magnitude after 22 seconds and at maximum brightness is shown 
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GRB 


Telescope 


Limit 


EXPTIME [sec] 


020531A 


Bootes-1 


10.5™ before and 8™after 


120 


021201A 


Bootes-1 


10™ 


45 


030115A 


Bootes-1 


10™ 


45 


030226A 


Bootes-1 


11.5™ 


180 


040825A 


Pi of the Sky 


10"^ 


10 


041211A 


Ashra prototype 


11.3™ 


? 


050215B 


Bootes-2 


10.0™ 


30 


050412A 


Pi of the Sky 


11"^ 


10 


050504A 


Ashra P2/3 


8™ 


4 


050408A 


WIDGET 


10.9™ 


5 X 10 


051211A 


Bootes-2 


10.0™ 


30 


060211A 


WIDGET 


10.8™ 


5 ( co-added ) 


060413A 


WIDGET 


10.0™ 


5 ( co-added ) 


070521A 


Pi of the Sky 


12"^ 


10 


070616A 


WIDGET 


11.8™ 


5 ( co-added ) 


070704A 


FAVOR 


13.0™ 


0.128 



Table 4.11: Optical limits derived from images started before the GRB outburst and simulta- 
neous to 7-ray emission. 
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4.5 Interpretation of results 

4.5.1 Constraints on bright optical flashes related to GRB 

As described in Section 11.0.31 it is expected that a large fraction of the GRB 
events cannot be observed from the Earth in 7-rays ( |33| , [SjJ ). These are so 
called orphan afterglows because in many cases only optical counterparts of such 
events could be observed from the Earth. It is also expected that a part of GRBs 
having small Lorentz factor are failed GRBs and do not give significant signal in 



7-rays ( [32| , [3ll| )• They also could be observed in longer wavelengths. The 
number of such events on the whole celestial sphere depends on the model and 
it is not well established. Recently, a few experiments determined limits on the 



number of classical ( long time after the GRB event ) orphan afterg 



ows on the 



whole celestial sphere ( [36|| , [37l| ). However, there are models ( [35|| , [3l| , 
32| ) suggesting that collimation maybe diff'erent for different wavelengths. Thus 
short optical flashes maybe related to GRBs for which 7 emission is pointing 
elsewhere. The "Pi of the Sky" experiment is a good tool to observe this kind 
of events due to its flash recognition algorithm. The observed flash events can 
be considered as candidates for optical flashes related to GRB events without 
detected 7-ray counterpart and used to derive constraints on the number of such 
events on the whole celestial sphere. The number of orphaned optical flashes 
corrected for the eflficiency of flash identiflcation algorithm can be derived from 
the following formula : 

Noa = ,^11^ (4.1) 
^ obs ' ^algo 

where T^bs is the total observing time normalized to 4-7r, N flashes is the num- 
ber of optical flashes observed in this period and eaigo is the efficiency of the flash 
recognition algorithm. The Table [442] shows the results for a single image flashes 
and flashes visible on more then 1 image of unknown origin. The column Olcorr 
( 5-th ) contains number of flashes corrected for limited efiiciency of flash iden- 
tiflcation procedure which was determined in Section 13.2.41 ( see equation 13.201 

)■ 
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Time Period 


Algorithm 


#OT/day/47r 


#OT/year/47r 


#OTco,.r/year/47r 


20040913-20050807 


Coinc ( Carl Zeiss ) 


90/1.68 


19554 


55869 


20050312-20050807 


ConfirmOnNext ( Carl Zeiss ) 


5/0.8 


2281 


6518 


20060512-20060725 


Coinc ( Canon 85mm ) 


35/0.14 


89336 


255246 


20060601-20070828 


ConfirmOnNext ( Canon 85mm ) 


1/0.78 


471 


1346 


20060601-20070828 


Flash algo in 240s timescale 


<l/0.69 


<529 





Table 4.12: Upper limits for number of short timescale orphan afterglows determined from the 
"Pi of the Sky" data 



The strongest limit comes from the algorithm requiring a presence of a flash 
candidate on at least 2 consecutive 10s images. The derived number means that 
there is not more optical flashes brighter then 12"^ then 3.69/day/47r. This is not 
very strict limit if we realize that it is only related to rather bright flashes, but 
it is comparable to the expected number of GRBs on the whole celestial sphere 
which is 2-3/day/47r. This number will be used in the next section to derive 
constraints on collimation of prompt optical emission of GRBs. 



4.5.2 Constraints on collimation of optical emission 

According to presented earlier theoretical predictions, optical signal from GRBs 
can be emitted in a larger angle then a 7 signal. In such a case it should be possible 



to observe short optical flashes related to GRBs w 



lich do not have corresponding 



7-ray counterpart visible from the Earth ( [35fl , [Slfl , |32| ). The constraint on 
collimation angle of optical emission will be determined under the assumption 
that 5 optical flashes observed on at least 2 consecutive images are related to 
GRBs which did not have a corresponding 7 detection. Number of optical flashes 
related to GRBs without 7-ray detection is related to number of those detected 
in gamma rays by the following formulae : 

#^=(^)' (4.2) 

-'■^ -y— visible \ P-y J 

where angles aoT and are deflned in Figure 14.91 and Noii-qrh denotes all 
events related to GRBs which can be observed from the Earth either in optical 
or in gamma band. The events that can be observed by the "Pi of the Sky" 
system are only those brighter then 12™^. The number of such events among all 
GRB events can be estimated from the SWIFT data. The analysis of optical 
light curves of SWIFT GRBs, similar to the one presented in Tab. 14.151 yields 
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Figure 4.9: A model of an emission mechanism of a GRB with difference in collimation of 7-ray 
and optical emission. There may be a number of events related to GRBs, but invisible in 7 
band from the Earth. 

that about a~8% of events have optical observations or brightness extrapolated 
to time T=0 brighter then 12™, which means : 

N-y+OT<12m = a ■ N^+OT (4.3) 

Now if we assume that events which do not have 7-ray counterpart are not 
optically brighter then those which have, we can write : 

NNo--y+OT<12m = " < « " NNo--y+OT (4.4) 

where Nj^^o-'^+ot are GRBs with no 7-ray observations, Nj^o_^j^oT<i2m are 
same events, but brighter then 12"^ and ai=a is assumed. The resulting number 
of optical flashes N^,^ flash can be used to calculate the upper limit for a number 
of orphan afterglows is : 

AT N]\fo-j+OT<12m ^ Nj^^ flash at o/J t a r\ 

Nmo-^+ot = < ~ 45.8/rfay (4.5) 

' ^algo 
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where eaigo ~ 0.35 stands for efficiency of a flasli recognition algoritlim ( Sec. 
13.2.41 ) and the strictest obtained limit NT^^fiash = 1-28 was used. This means that 
a number of optical flashes related to "invisible" GRBs, should not be greater 
then 21.5 / day. Thus number of all GRBs visible from the Earth either in optical 
or gamma-ray band can be constraint as follows : 



Nall-grb < Nno-'J+OT —visible 

^ 45.8 + 2.5 = 48.3/day (4.6) 

where a number of all GRBs which can be observed from the Earth was 
assumed to be N^-msibie ~ 2.5 . This gives the constraint on a ratio of the 
collimation angles : 



\ 2 

aoT \ Nall-grb 



P7 / 'y— visible 



which gives : 



aoT < 4.4 ■ [3^ (4.8) 

This limit means that collimation of optical emission is not more then ~ 4.4 
times larger then collimation of 7-ray emission. Collection of more data will 
improve this limit significantly. It is possible to compare the obtained result on 
/c ~ 19.3 with the results obtained in 58| and [5^ which are 75±25 and 500, 
respectively. However, one must keep in mind that these results were obtained 
for classical afterglows, which are long duration optical counterparts of GRBs, 
observed hours/days after the GRB event. 

4.5.3 Limits on the optical luminosity of the GRB source 

Using measurements of optical counterparts obtained by other experiments and 
early brightness limits presented in the previous section, the limitations on the 
optical luminosity of the GRB source were determined. They were compared 
with the measurements of other optical telescopes. The observed magnitudes 
were corrected for the galactic extinction. The luminosity distance to the source 
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was calculated in the cosmological model with ^Ix = 0.7 and f2jv/ 
luminosity of the source was calculated according to formula : 



1 + z 



■k 



0.3. Then 



(4.9) 



where k is cosmological k-correction ( which was not taken into account here 
) and f is flux , calculated from magnitude with the following formula : 



/ = /o ■ 10-°-' "^ (4.10) 

The luminosity in function of time with the limits determined in this thesis is 
shown in Figure [4.101 



ical luminosity in the source 




10 10^ 10^ lO"* 

Time since GRB in rest frame of tfie burst t_obs*(1+z) [sec] 



Figure 4.10: Optical luminosity of the source in function of time, up to 24 hours after the burst. 
The limits obtained from the "Pi of the Sky" measurements and presented in this thesis are 
shown. 



The measurements has been divided into time bins and Gaussian distribution 
was fitted in each time range. These fits are shown in Figure [4TT1 The resulting 
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mean values has been plotted against center value of the time. This dependency 
with fitted power law function is shown in Figure [4?T2l It is clearly well describing 
the optical luminosity of the GRB source in time. The obtained dependency is 
a quite astonishing result, because it was obtained from many different GRBs, 
which indicates that optical counterpart can have similar properties in many 
bursts. 

The similar analysis was performed in [60||. In that case a clustering of optical 
luminosities 12 hours after the burst was suggested, which is rather not observed 
in early times analysed in this thesis. 



4.5.4 Predictions for the full system observations 

Assuming luminosities from the range Lot=10^'^ — 10^* erg/s/Hz the object bright- 
ness was calculated as a function of redshift. This calculation is shown in Figure 
I4.13[ The obvious result is that for redshifts higher then z=3 only extremely 
bright bursts can be visible with the "Pi of the Sky" telescope. However, SWIFT 
satellite detector works in 15-350 keV which is rather soft, thus it is more sensi- 
tive to more distant GRBs ( with high redshift ) . The distribution of z for the 
pre-SWIFT and SWIFT bursts is shown in Figure 14.151 It can clearly be seen 
that contrary to previous satellites most of the SWIFT bursts are more distant 
then z=2. The detector observing in harder bandpass ( like GLAST , 10 MeV - 
100 GeV ) would have higher chance to detect close bursts and thus brighter also 
in optical band ( Sec. 11.0.2.11 ). 

The region above z=5 is only a theoretical prediction and due to neutral 
hydrogen present in this region ( not taken into account here ) theoretical lines 
cannot be treated as realistic shape. The conclusions is that the brightest optical 
counterparts can be observed up to z~4 and weak bursts can be observed by 
the "Pi of the Sky" system only if they occurred relatively close (z<0.2). This 
predictions can be compared with the acceptance of the GRB detecting satellites 
presented in Figure I4.14[ It can clearly be seen that SWIFT satellite has best 
acceptance for bursts with z>2 , which strongly limits chances to observe optical 
counterpart by the "Pi of the Sky" system. However, GLAST satellite which 
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Figure 4.11: Distributions of luminosity in subranges of time with fitted gauss function 
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Figure 4.12: Luminosity of the source in function of time since GRB. 
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Figure 4.13: Optical brightness obtained for different source luminosities in function of redshift 



4.5 Interpretation of results 




Figure 4.14: Observed 7-ray energy -Bpg^^. in function of redshift at which GRB occurred. 
Calculated for E^"^]^"" energies of 2.0MeV, 1.5MeV, IMeV and 500keV. 
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will be launched in 2008 will have good acceptance much wider range of gamma 
energies. 
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Figure 4.15: Distributions of redshifts of pre-SWIFT and SWIFT GRBs 



Thanks to the launch of a SWIFT satellite in the fall of 2004 it is possible 
to observe optical counterparts of GRBs at very early time. Table 14.131 shows 
the number GRBs observed by SWIFT in subsequent years. On average less 
then Ri50% of all GRBs have observed optical counterparts. Figure 14.161 shows 
the distribution of the minimal time of the optical counterparts observations and 
reaction time of optical telescopes ( including robotic and SWIFT-UVOT ) The 
reaction time peaks at ~ 110 seconds, and it is clear that early times ( at T=0 
) are very poorly covered. It is also clear that SWIFT-UVOT telescope covers 
only optical data starting from > 60 sec, due to the time needed to slew the 
spacecraft. This early period can only be covered by fast robotic telescopes or 
wide FOV system like "Pi of the Sky" with negative reaction time. 
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Figure 4.16: Distribution of reaction times (<400 sec) of all optical telescopes and SWIFT- 
UVOT shown separately (left plot) and minimal time of positive optical detection (right plot). 
Only Swift GRBs were taken into account. 



Period 


Number of GRB 


Number of GRB 
with observed OT 


2004.12.17-2004.12.31 


3 


1 


2005.01.01-2005.12.31 


87 


43 


2006.01.01-2006.12.31 


105 


63 


2007.01.01-2007.10.13 


68 


38 



Table 4.13: Number of GRBs observed by SWIFT with number of those for which optical 
counterpart was observed 
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GRB 


Maximum 
brightness 


Filter 


First observa- 
tion time fs] 


Telescope 


GRB 071003A 


12.83 


none 


42 


MERGE,KAIT 


GRB 061126A 


12.3 


none 


21 


RAPTOR 


GRB 061007A 


10.15 


R 


142 


ROTSE,FTS 


GRB 060117A 


11.5 


R 


124 


FRAM 


GRB 060111B 


13.0 


none 


27 


TAROT,ROTSE 


GRB 051111A 


13.0 


none 


27 


ROTSE 



Table 4.14: The brightest optical counterparts ( called "guaranteed" in the text ) of GRBs 
observed by SWIFT, which could be detected by "Pi of the Sky" if it appears within the range 
of the telescope. Observed in the time period 2005.01.01-2007.10.20. 



The full "Pi of the Sky" system will be a perfect tool for covering this early pe- 
riod of optical observations. According to the current SWIFT data it is possible to 
make conservative estimate on the number of events for which the system would 
see the signal from GRB optical counterpart. All GRBs detected by SWIFT 
were analysed and events with observations in the first 15 minutes after the burst 
were selected. Let us divide them into four classes according to "Pi of the Sky" 
observability : 

• Guaranteed : events which have observations brighter then 13™ and would 
certainly be detected by the "Pi of the Sky" experiment ( Tab. 14.141 ) 

• Marginal : events which have observations brighter then 15"^ and early 
observation of such events would have great scientific significance 

• Extrapolated : events which don't have observations brighter then 15"^ 
but light curve of early points extrapolated to time T=0 sec is brighter then 
15"^. 

• Beyond Limit : events with brightest measurements far below limiting 
magnitude of the "Pi of the Sky" experiment 

Table [4T5] shows the classification results. It can be seen that 2.3-18% of all 
GRBs could be detected if they appear in the FOV of the "Pi of the Sky" system. 



4.5 Interpretation of results 



Observation prediction 
for "Pi of the Sky" 


Number of GRB 
(2005-2006) 


% 


Guaranteed 


6 


2.3 


Marginal 


20 


7.7 


Extrapolated 


20 


7.7 


Beyond Limit 


183 


70.1 


No early observations 


32 


12.3 


Total GRB# 


261 


100.0 



Table 4.15: Number of GRBs in different prediction groups 



The estimate of the number of events to be observed by the full system is derived 
from the following formula : 



p^SWIFT 

Nu-OT/year = rpSWIFT ^ f Swift- FOV ^ fcoll, 
total 



f — f f (4-11) 

J Swift— FOV ■ — J night ^ Jsatfovi 
ftot • f night ^ fsatfov ^ fcoll 

where Nf^/^'^ is the number of events of given type observed by SWIFT in 
period TfJ^/^^, f night is the fraction of time which can be used for observations 
at given site, fsatfov is the fraction of night when SWIFT satellite is above the 
horizon, fcoii is the fraction of nights when weather was good enough to collect 
data and the system was functional. The value fswift-Fov was calculated for 
period of one year under assumption that system collects data only when hsuN < 
10° and using SWIFT pointing information from period 2005-2006. The value 
of FOV acceptance fsatfov was calculated in conservative way assuming that it is 
possible to observe SWIFT's FOV when it is at h>14° above horizon. However, 
due to large FOV of SWIFT it is possible to observe part of its FOV also when 
it is h<14°. The error coming from this should not exceed few percent. The 
value of fcoll ~ 81% coefficient was estimated for 2006.06.01-2007.10.25 collecting 
period. If we assume that most of the technical problems will be solved in the final 
system and data will not be collected only due to the bad weather condition this 
coefficient can be estimated by f weather ~ 91% ( in Las Campanas Observatory in 



4.5 Interpretation of results 



Chile ) . The values of coefficients for different sites are shown in Table I4.16[ La 
Palma site was shown as an example of possible Northern hemisphere location of 
the "Pi of the Sky" system. 



Site 


Value of fsivift-Fov 


fcoll 


f weather 


ftot 


ftot — max 


LCO 


15% 


81% 


91% 


12% 


14% 


La Palma 


23% 


65% 


75% [61] 


15% 


17% 



Table 4.16: Values of coefficients used to calculate tt acceptance for SWIFT GRBs. The value 
of ftot-max was Calculated under the assumption that the system will not loss any night due to 
technical problems and fcoU = f weather 



OT Class 


Site 


# of OT in 
2005-2007 


Expected # oi 
observations / 
year 


Guaranteed 


LCO 


6 


0.28 


Marginal 


LCO 


20 


0.9 


Extrapolated 


LCO 


20 


0.9 


Total LCO 


LCO 


46 


2.08 


Guaranteed 


La Palma 


6 


0.34 


Marginal 


La Palma 


20 


1.1 


Extrapolated 


La Palma 


20 


1.1 


Total La Palma 


La Palma 


46 


2.54 



Table 4.17: Expected number of events observed by full tt system. Values were obtained under 
assumption of the failure free system only Hmited by the weather conditions. 

The final estimates for numbers of events of given class are listed in Table 
I4.17[ It can be seen that number of sure positive observations is very small. 
However, it must be stressed that period at T=0 moment is almost unknown. 
The estimation is conservative, GLAST satellite will increase the value of fsatfov 
coefficient. 

There is also an advantage of observing short GRBs during the 7-ray outburst. 
The numbers shown in Table 14.171 are safe estimates according to what is already 
observed for long GRBs. They show big chances of observing positive signal 
of great scientific significance in the first 2 years of the experiment and thus 
can be considered as optimistic. It is important that in fact only a few optical 



4.5 Interpretation of results 



counterparts of Swift GRB were observed in T=0 by optical telescope [22|, thus 
it is not well known what can be expected. The predictions in Table 14.171 are 
determined according to observations performed several dozens of seconds after 
the burst. 



Chapter 5 
Summary 



The prototype system is working since July 2004. In this period it observed FOV 
33° X 33° during 322 nights. Since June 2006 FOV 20° x 20° was observed during 
276 nights. During the entire period satellites detected 231 Gamma Ray Bursts, 
3 events occurred in the field of view of the "Pi of the Sky" prototype system. 
In 35 cases the burst occurred outside the FOV and the position was observed a 
few minutes after the 7 detection. Optical counterpart was not observed in any 
of the cases. The upper limits on the optical brightness have been determined for 
all 38 events. 

The algorithms for identification of optical fiashes and brightness variations 
has been designed and tested on the collected data. The automatic on-line al- 
gorithms have discovered 135 optical flashes visible in single 10s image on two 
cameras working in coincidence and 6 flashes visible in at least 2 consecutive 
images, but only on single camera ( second was not working ). One of these 
flashes has been unambiguously identified as the outburst of the known fiare star 
CN Leo. This confirmed efficiency of the experiment strategy. The off-line algo- 
rithm for identification of brightness increases automatically discovered outburst 
of known star system GJ3331A/GJ3332. The off-line "nova-algorithm" finding 
new objects appearing in the sky during normal observations was well tested on 
the asteroids which imitate events of nova-like signature. The short optical fiash 
visible on at least 2 consecutive images found in the second period of data col- 
lection was used to derive upper limit on the ratio of optical to 7-ray collimation 
of the prompt emission, which is i? < 4.4. The full system will allow to improve 



this limit by at least a factor of 16 ( under assumption the system will consist 
of 16 cameras ). Number of predicted positive observations of the optical coun- 
terparts of GRBs is ~ 2.5 events/year. This gives very optimistic perspectives of 
obtaining meaningful scientific results. 



Appendix A 



Technical Details on system controU 



A.l Libraries and programs for data aquisition 
and analysis 

Table below lists libraries which were in big part developed by author and are 
components of Data AQuisition and Data Analysis programs. Paths to source 
location are relative and should be proceeded with /opt/pi/dev/pisys/daq/src/. 

Table below lists most important programs for collecting data and photometry 
and astrometry. 



A.l Libraries and programs for data aquisition and analysis 



NAME 


LIBRARY FILE 


SOURCE LOCATON 


DESCRIPTION 


baselib 


libbaselib.a 


cmn/baselib/ 


low level common classes for file handling, date/time etc 


mathlib 


libmathlib.a 


cmn/mathlib/ 


mathematical functions 


log4pi 


liblog4pi.a 


cmn/log4pi/ 


interface for logging to sysylog 


pidblib 


libpidblib.a 


ccd/pidblib/ 


postgres database interface 


asaslib 


libasaslib.a 


ccd /fitslib /asaslib / 


procedures adopted from ASAS experiment 


myfitslib 


libmyfitslib.a 


ccd/fitslib/myfitslib/ 


classes for fits files I/O 


cfglib 


libcfglib.a 


ccd/cfg/ 


definitions of default values of paramters 


picamdrv 


libpicamdrv.a 


ccd/ccddriver/picamdrv/ 


camera driver library 


ccdscript 


libccdscript.a 


ccd/ccdscripts/ 


script generator and pointing classes 








interfece to external library tor calculating satellites 


ccdsat 


libccdsat.a 


ccd/ccdsat/ 


positions 


ccdlib 


libccdlib.a 


ccd/ccdlib/ 


mam data aquistion library, implementmg classes tor 
image collection and on-line analvsis 


ccdinterface 


libccdinterface.a 


ccd/ccdinterface/ 


mterface classes to communicate with other parts of 
the svstem and external world 


ccdastro 


libccdastro.a 


ccd/ccdastro/ 


library for astronomical fomulae 



Table A.l: Most important libraries developed for data collection and analysis 



PROGRAM NAME 


SOURCE LOCATION 


DESCRIPTION 


ccdsingle 


ccd/TESTY/ccdsingle/ 


program for collection and analysis of images from single camera 


ccddouble 


ccd/TESTY/ccddouble/ 


program for collection and analysis of images from two cameras 


test2K2K 


ccd/TESTY/test2K2K/ 


program for operating cameras in interactive mode. 'I'he usage of the 
program is the following : test2K2K CAMERA OPTIONS In order to 
specify camera, its name k2a, k2b, etc can used or if unknown the 
number 0,1,2, etc. In order to specify IP adress of the camera option 
-eth=100. 100. 100.1 must be provided. For more details see web page : 
http://hep.fuw.edu.pl/ msok/test 2K2K.html 


piastrometry 


ccd/TESTY/piastrometry/ 


program for running astrometry 


piplioto 


ccd/TESTY/piphoto/ 


program for fast photometry algorithm 



Table A. 2: Most important programs for data aquisition and analysis. All programs show short 
help when launched with option -h 



A. 2 Description of FITS header keywords 



A. 2 Description of FITS header keywords 

The table below lists keywords saved to fits header files. 



A. 2 Description of FITS header keywords 



KEYWORD 


DESCRIPTION 


Standard FITS format keywords 


SIMPLE 




Mandatory, T if conforms to standard, F otherwise 




BITPIX 




Mandatory, number of bits representing data value 




NAXIS 




Mandatory, number of axis in dat array 




NAXISl 




Mandatory, number of elements along X axis 




NAXIS2 




Mandatory, number of elements along Y axis 




EXTEND 




T if FITS may contain extensions 
Used in case array value are not physcial, but : physical 


value = 


BZEHO 




BZERO + BSCALE * array value 

Used in case array value are not physcial, but : physical 


value = 


BSCALE 




BZERO + BSCALE * array value 




Observed object description 






Name ol object or held observed, project conention is 


syntax : 


OBJECT 




HOOOO-l-00, where letter is first letter of object name and dig 


its stand 


ROTATE 




for coordinates : HHMMiDD 

if image is rotated ( / 1 ) 




DRVFLIP 




if imaged was fliped by driver on PC side ( / 1 ) 




RA 




Right Ascension of image center in hours decimal 




DEC 




Declination of image center in degrees decimal 




HA 




Hour angle of image center in hours decimal 




AZIM 




Azimuth of image center in degrees decimal 




ALT 




Altitude of image center in degrees decimal 




ZENITH D 




Zenithal distance of image center in degrees decima 




OBSMODE 




Observation mode - - mount not tracking, 1 - mount tracking 


AVERAGE 




Mean pixel value on image 




RMS 




RMS of pixel value on image 




Observing Site 


ORIGIN 




Name of project 




SITE 




Code of site, LCO - Las Campanas, BRW - Brwinow 




TELLONG 




Geographical longitude [deg] 




TELLAT 




Geographical latitude [deg] 




TELALT 




Altiutude above the see level [m] 




Instrument 


INSTRUME 




Name of instrument 




CAMERA 




Name of camera 




CAMOPTIC 




Camera optic description 




FILTER 




Used filters 




PIXSCALE 




Angular size of pixel [ arcsec ] 




PIXSIZE 




Physcial size of pixel [ ;j.m ] 





A. 2 Description of FITS header keywords 



KEYWORD 


DESCRIPTION 


Exposure id 


OBSERVER 


Observer name 


DIMAGE 


Image number ( during single night ) 


NIMAGE 


Obsolate 


SOFTWARE 


Software version 


BUILD 


Software build date and time 


DRVTYPE 


Camera driver type 


CAMID 


Camera ID ( 2-k2a, 3-k2b ) 


CAMIIDX 


Camera internal index 


FILENAME 


FITS file name 


Exposure settings 


hj r L 1 ivi cj 


ReQui r e exposure 1 1 me [sec] 


JvHj-j^x^ L llVlCj 


lV4easured exposure time [sec] ^ not very precise ^ 






SHUTMODE 


Shutter mode O P Ej N Fj D - p ermanent ly opened^ N C A.L - ope ny^ close mode 


ADCGAIN 




ADCBIAS 


ADC offset value [mV] 


ADCGSET 


ADC gain setting value 


LNAGAIN 


Low Noise pre-Amplifier (LNA) gain value x8 or x20 ( current value is x8 ) 


ADCBSET 


ADC offset setting value 


ADCRANGE 


2V or 4V 


ADCCLAMP 


ADC Clamping 2V or 4V 


ELECGAIN 


Gain of camera [e/ADU] 


COOLING 


Cooling enabled / disabled ( YES / NO ) 


ABINN 


Analog binning ( disabled ) 


SBINN 


Software binning ( disabled ) 


SPEED 


OBSOLATE 


SPEEDMH 


Speed description Vertical / Horizontal - to be corrected (horizontal is missing ) !!! 


MPP BC 


Multi-pinned phase or BC mode 


RO-TIME 


Measured data transfer time [sec] ( from camera RAM to PC ) 


CROTIME 


Measured chip readout time [sec] 


FOCUS 


value of current step motors position [steps] 


HITLENS 


Lens hitting ON/OFF 


SAVEAREA 


Area of chip saved in this FITS file [x start y start x end y end] 


USBMODE 


USB mode ( 1.1 or 2.0 ) 


FPGAVER 


FPGA firmware version date 


CPRSVER 


Cypress firmware version date 


VERDESC 


Camera Firmawre version description 


RNOISE 


readout noise [ADU] - to be verified !!! 


RELNOISE 


readout noise [e] - to be verified !!! 


Exposure environment 


CHIPTSET 


Required chip temperature [Celsius] 


CHIPTEMP 


Measured chip temperature [Celsius] 


CHIP TEM 


Measured chip temperature [Celsius] 


CASTEMP 


Measured case temperature [Celsius] 


AMBTEMP 


Measured ambient temperature [Celsius] 


CAMHUMID 


Measured camera humidity 


AMBHUMID 


Measured ambient humidity 


INTRTEMP 


Not implemented 


AIRMASS 


Airmass - not implemented 


DOME 


Dome status : OPENED / CLOSED 



A. 2 Description of FITS header keywords 



KEYWORD 


DESCRIPTION 


Exposure date 


UT-START 




UT time of image start 


DATB-OBS 




UT date of image start 


DATE OBS 




Local date of image start 


TIME UT 




unixtime of image start [sec] 


UT-END 




UT time of image end 


TIME OBS 




UT time of image end 


DATE-END 




UT date of image end 


LOCTIME 




local time of image start 


LOCDATE 




local date of image start 


EPOCH 




current epoch 


EQUINOX 




current equinox 


ST 




siderial time [radians] 


JD 




Julian date 


HJD 




Heliocentric Julian date 


Astrometry 


ASTROOK 




Astro OK or FAILED ( 1 / ) 


POSANGLE 




Rotation angle [deg] 


AST ORD 




Order of transformation equation ( 4 ) 


ASTUTIME 




unixtime of astrometry ( if not performed on every image ) 


AST ERR 




Error of astrometry [pixels] 


PAR X 0, PAR X 0, ... 


PAR X 13 


Coefficients of astrometric transformation 


PAR Y 0, PAR Y 1, 


PAR Y 13 


Coefficients of astrometric transformation 


Photometry 


NSTARS 


Number of stars detected on image 


Mount 


MOUNTHA 




Right Ascension as obtained from mount [hours decimal] 


MOUNTDEC 




Declination as obtained from mount [degrees decimal] 


MOUNTAZ 




Azimuth as obtained from mount [degrees decimal] 


MOUNTTRK 




Tracking mode as obtained from mount [0-non tracking, 1-tracking] 


MOUNTTM 




Timestamp of mount information 


MOUNTHA 




Hour angle as obtained from mount [hours decimal] 


MOUNTALT 




Altitude as obtained from mount [degrees decimal] 


MOUNTDTM 




Timestamp of mount information [unixtime - sec] 


MOUNTMV 




If image taken just after mount move ( / 1 ) 



Table A.3: Keywords in FITS files 



A. 3 System log files 



A. 3 System log files 



The most important log files are listed in table below : 



LOG FILE NAME 


DESCRIPTION 


pi. log 


log file from all modules written by syslog daemon 


run daq YYYYMMDD.out 


standard output from DAQ program ( eedsingle or eeddouble ) 


mount. logfile YYYYMMDD HHMMSS 


mount eontroU program log file 


piman.logfile YYYYMMDD HHMMSS 


piman server log file 


gen server.log 


log file of listener program receiving and redireeting GCN messages to gen program 


gen. logfile 


log file of gen program sending alerts to piman server 


gen imalive. logfile YYYYMMDD 


log file containing I'am alive packets from external GCN server 


integral pointdir.log 


INTEGRAL satellite pointing information obtained from GCN server 


swift pointdir.log 


SWIFT satellite pointing information obtained from GCN server 



Table A. 4: Most important log files from 7r-system, files are stored in directory 
/opt/pi/dev/pisys/log/, unless different path is specified, YYYYMMDD is date ( for exam- 
ple 20070101 ) and HHMMSS is time ( for example 200112 ) 



A. 4 DAQ controll from piman and pishell 



A. 4 DAQ controll from piman and pishell 



PISHELL COMMAND 


FUNCTION NAME 


INPUT 


DESCRIPTION 


start daq 


StartDAQ 




starts dark collection and sets daq 
to , , , , , 


- 


IsDaqStarted 


- 


returns 1 i± UAQ is already started, 
n otherwise 


start analysis 


Start Analysis 


mount position (RA,DEC) 


sets new position and starts image 
collection and analysis 


stop analysis 


StopAnalysis 




stops image collection ( but waits 
for last image to be finished ) 


stop analysis nowait 


Stop AnalysisNo Wait 




stops image collection without wait- 
ing for last image 




SendAlert 


GGN alert time and position 


informs UACj about GGiN trigger 
which is being observed 




SetOnTriggerPosition 


Alert position (RA,DEG) 


starts image collection alter trigger 
is recpived 


fast post to daq 


Correct Mount Posit ion 


mount position (RA,DEC) 


corrects mount position 


dodarks 


DoDarks 


N 


collects N dark images 


take npictures 


TakeNPictures 


N 


collects N images 


take npictures synchro 


TakeNPicturesSynchro 


N 


collects N images in synchronize mode 


set cooling 


SetCoolingOnOff 


temperature and camera 


sets temperature for given camera 


change par am 


ChangeParam 


param name, value and camera 


changes parameter of daq 


stat 


GetStatus 




returns status of daq program 


set fits key 


Set Gust omKey 


fits header key name and value 


sets value of specified fits header key 



Table A. 5: Functions exported by DAQ 



A. 5 System controll commands 



A. 5 System controll commands 

Example of night script for automatic system controll : 



A. 6 Observation targets 

The table below lists observation targets in decreasing order of priority 



A. 6 Observation targets 



# auto-generated script 

# night : 20060605 

# camera : Cannon EOS f=85imn 

# system start time is : 20060605_180643 local ( 20060605_220643 UT ) 

# PRIMARY SATELLITE = INTEGRAL 

# SECONDARY SATELLITE = HETE 

# SUN sets at 1840 LCO time, at (AZ ,H)=(110 .44, -9 . 90) [deg] 

# SUN rises at 0645 LCO time 

# SWIFT at 20060605,180643 local time is at (RA,DEC)=(144 . 94 , 15 . 00) 

# HETE info file date : 20060605,072000 

# HETE RA=249.05=16h36ml2.00s DEC=-63.06 

# HETE rises above horizont at 327, sets at 116 

# hete at h_hete >= 30.00 at 1901 

# MOON RA=190.54=12h42ml0.68s DEC=-5.28 ilium = 72.06 °l. 

# MOON uill set at 20060606,025143, ilium = 73.46 

# INTEGRAL RA=125.47=08h21m52.32s DEC=-47.51 

# INTEGRAL rises above horizont at 737, sets at 36 
piman cron_point_hete_of f 

piman 1 exec_script_synchro(startup.pish) 
# 

daq 1825 start_daq 

piman 1825 auto_ag_mode_on 
piman 1830 manual_mode_of f 

# Following INTEGRAL at (RA ,DEC)=(125 .47 , -47 . 51) (az,h)=(46.77,55.89) 

# Closest field (RA,DEC)=(128 . 50 , -50 . 00) , (az ,h)=(41 . 23 , 56 . 76) => 0BJECT=I0834-50 

# At 1920 field (RA,DEC)=(128 . 50 , -50 . 00) of object INTEGRAL is at (az ,h)=(45 . 10 ,50 . 74) 

# turning OFF cron 
piman 1840 manual_mode_on 

# internal 1149547243 goto_ra_dec(128 . 50 , -50 . 00) 
piman 1840 cron_point_hete_of f 

internal 1840 goto_ra_dec_auto_corr (128 . 50 , -50 . 00 , 10834-50) 
mount 1840 raw_cmd(autoguide on) 
internal 1840 send_pos_to_mount 
mount 1840 stat 

piman 1845 cron_send_pos_to_mount_on 
internal 1850 send_pos_to_mount 
mount 1850 stat 

# turning ON cron 

piman 1850 manual_mode_of f 

# End of tracking (ra,dec)=(128 . 50 , -50 . 00) at 2155 , (az,h)=(45.26,26.05) deg 



A. 6 Observation targets 



piman 1900 manual_mode_on 

piman 1900 cron_point_hete_of f 

piman 1900 croii_seiid_pos_to_mount_of f 

piman 1900 exec_script_synchro(scan_evening.pish) 

piman 1930 manual_mode_of f 

# Follouing INTEGRAL at (RA ,DEC)=(125 .47 , -47 . 51) (az,h)=(49.99,47.46) 

# Closest field (RA,DEC)=(128 . 50 , -50 . 00) , (az ,h)=(45 . 79 ,48 . 99) => 0BJECT=I0834-50 

# At 2010 field (RA,DEC)=(128 . 50 , -50 . 00) of object INTEGRAL is at (az ,h)=(47 . 14,42 . 62) 

# turning OFF cron 
piman 1930 manual_mode_on 

# internal 1149550254 goto_ra_dec(128 . 50 , -50 . 00) 
piman 1930 cron_point_hete_of f 

internal 1930 goto_ra_dec_auto_corr (128 . 50 , -50 . 00 , 10834-50) 
mount 1930 rau_cmd(autoguide on) 
internal 1930 send_pos_to_mount 
mount 1930 stat 

piman 1935 cron_send_pos_to_mount_on 
internal 1940 send_pos_to_mount 
mount 1940 stat 

# turning ON cron 

piman 1940 manual_mode_of f 

# End of tracking (ra,dec)=(128 . 50 , -50 . 00) at 2145 , (az,h)=(45.64,27.43) deg 

# Following HETE at (RA ,DEC)=(249 . 05 , -63 . 06) (az,h)=(334.65,47.49) 

# Closest field (RA,DEC)=(255 . 00 , -60 . 00) , (az,h)=(328.70,46.52) => 0BJECT=H1700-60 
internal 2140 send_pos_to_mount 

# At 2225 field (RA,DEC)=(255 . 00 , -60 . 00) of object HETE is at (az,h)=(332.55,50.84) 

# turning OFF cron 
piman 2145 manual_mode_on 

# internal 1149558354 goto_ra_dec(255 . 00 , -60 . 00) 
piman 2145 cron_point_hete_of f 

internal 2145 goto_ra_dec_auto_corr (255 . 00 , -60 . 00 ,H1700-60) 
mount 2145 raw_cmd(autoguide on) 
internal 2145 send_pos_to_mount 
mount 2145 stat 

piman 2150 cron_send_pos_to_mount_on 
internal 2155 send_pos_to_mount 
mount 2155 stat 



A. 6 Observation targets 



# turning ON cron 

piman 2155 manual_mode_of f 

# End of tracking (ra,dec)=(255 . 00 , -60 . 00) at 0630 , (az,h)=(33.97,26.78) deg 

# morning 

piman 0545 manual_mode_on 

piman 0545 cron_point_hete_of f 

piman 0545 cron_send_pos_to_mount_of f 

piman 0550 exec_script_synchro(scan_morning.pish) 

piman 0615 manual_mode_of f 

# HETE (RA,DEC)=(249.05,-63.06) at 0615 is at (AZ ,H)=(30 . 32 , 26 . 21) 

# Waiting for HETE at (RA,DEC)=(252 . 96 , -63 .41) (az,h)=(30.32,28.00) 

# Closest field (RA,DEC)=(255 . 00 , -60 . 00) , (az ,h)=(34 . 32 , 28 . 39) => 0BJECT=H1700-60 

# At 0655 field (RA,DEC)=(255 . 00 , -60 . 00) of object HETE is at (az ,h)=(33 . 00 , 23 . 52) 

# turning OFF cron 
piman 0615 manual_mode_on 

# internal 1149588948 goto_ra_dec(255 . 00 , -60 . 00) 
piman 0615 cron_point_hete_of f 

internal 0615 goto_ra_dec_auto_corr (255 . 00 , -60 . 00 ,H1700-60) 
mount 0615 rau_cmd(autoguide on) 
internal 0615 send_pos_to_mount 
mount 0615 stat 

piman 0620 cron_send_pos_to_mount_on 
internal 0625 send_pos_to_mount 
mount 0625 stat 

# turning ON cron 

piman 0625 manual_mode_of f 

# End of tracking (ra,dec)=(255 . 00 , -60 . 00) at 0630 , (az ,h)=(33 . 91 ,26 . 55) deg 

# Do not uorry about order, these tuo commads aluays go just before shutdown : 
piman 0640 cron_point_hete_of f 

piman 0640 cron_send_pos_to_mount_of f 
piman 0650 exec_script(shutdown.pish) 



Figure A.l: Example of night pish script 



A. 6 Observation targets 



OBJECT NAME 


POSITION 


INFO 


SWIFT Satellite 




FOV~2 staradians 


INTEGRAL Satellite 




FOV:^ 15° 


PKS 2166-304 


216862-301332.0 


blazar 


AO 0236 + 164 


023838+163669.0 


blazar 


4C 29.46 


116931+291444.0 


quasar 


OI 168 


073807+174219.0 


quasar 


OJ 287 


086448+200629.0 


quasar 


3C 273 


122906+020307.0 


quasar 


OR -017 


161260-090668.0 


quasar 


W Com 


122131+281368.0 


blazar 


J0210-6065 


021046-610100.0 


blazar 


OJ 049 


083148+042939.0 


blazar 


GeV J1832-2128 


183300-213600.0 


blazar 


OP 161 


133336 + 164904.0 


blazar 


PKS 0637-441 


063860-440608.0 


blazar 


Mrk 601 


166362+394636.0 


blazar 


Mrk 421 


110427+381230.0 


blazar 


QQ Vul 


200641+223969.0 


polar 


RR Aqr (D) 


211843-020812.0 


variable star 


RR Aqr 


211601-026344.0 


variable star 


RR Aqr (C) 


211917-014609.0 


variable star 


VV Pup 


081606-190316.0 


variable star 


EF Eri 


031413-223640.0 


polar 


V834 Cen 


140907-461717.0 


polar 


V2214 Oph 


171201-293732.0 


polar 


J0468-4636 


046660-461667.0 


blazar 


BL Hyi 


014100-676326.0 


polar 


MR Ser 


166247+186626.0 


polar 


4C 11.69 


223236+114360.0 


blazar 


OS 319 


161341+341247.0 


blazar 


3C 279 


126611-064721.0 


blazar 


V347 Pav 


184448-741833.0 


polar 


GQ Mus 


116202-671220.0 


polar 


RR Aqr (G) 


211622-023914.0 


variable star 


PKS 1229-021 


123169-022406.0 


blazar 



Table A. 6: List of objects to be automatically followed in order of priority 



Appendix B 

Technical Details on Data Analysis 

B.l Parameters of on-line flash recognition algo- 
rithm 



B.l Parameters of on-line flash recognition algorithm 



Parameter Name 


Parameter Name in conflguration file 


LaplaceType 


CCD LAPLACE TYPE 


T 


CCD_NEW_LAPLACE_TRESHOLD_IN_SIGMA 


V 

^aver 


CCD MAX LAPLACE ON OTHER IN SIGMA 
CCDAVERAGEOFPREVN 


T 

-'- MinLap 


CCDMINLAPLACEONOTHER 




CCD_MAX_NUMBER_OF_EVENTS_AFTER_TV 


enable/disable 

Roverlap 


CCDSKIPOVERLAPS 
CCDOVERLAPREDIAL 


T 

shape 


CCDCHECKEVENTSHAPE 


Thlack 


CCD_BLACK_PIXELS_RATIO 


Thot 


CCD_REJECT_HOT_PIXELS_BY_AVERAGE_TRESH 


NifMore 
RifMore 


CCD_SKIP_IF_MORE_THEN 
CCD_SKIP_IF_MORE_THEN_REDIAL 



Table B.l: Table translating FLT paramter names into real names used in configuration file 



B.l Parameters of on-line flash recognition algorithm 



Parameter Name 


Parameter Name in conflguration file 


Rcoinc 


CCD_COIC_RADIUS_IN_SEC 


N f 

' confirm. 


CCD_CONFIRM_ON_N_NEXT_FRAMES 


Rsat 


CCD_SAT_REJ_RADIUS_IN_SEC 


Rstar 

Magmax 


CCD_MATCH_STAR_TO_CAT_RADIUS_IN_ARCSEC 
CCD_STARCAT_MAX_MAG 


^track 

x' 


CCD_NUM_BACK_FRAMES_FOR_TRACK 
CCD_MAX_CHI2_F0R_P0INT_T0_MATCH_LINE 
CCD_MAX_CHI2_IN_TRACK 



Table B.2: Table translating SLT paramter names into real names used in configuration file 



Cut 


Parameter Name 


'though 
oughj-^ eight 


CCD HOUGH TRANSFORM TRESH 

CCD HOUGH DISTR TRESH 
CCD HOUGH DISTR MAX LIMIT 


NtstaTS 
^clouds 


CCD SLT TYPICAL STARS COUNT 
CCD SLT REJECT FRAME IF LESS 




CCD LAP DIFF MIN RATIO 


■jpTLT 


CCD NEW LAPLACE TRESHOLD IN SIGMA 



Table B.3: Table translating TLT paramter names into real names used in configuration file 
slt.cfg 
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